STM32 MCUs

The development board I am using is stm32h723. Assuming I only configured region 0 and wrote a blacklist, all regions (both privileged and non-privileged) are inaccessible. The remaining 15 regions were not configured. However, in the MPU Control Mode, I configured "Background Region Privileged access only + MPU Disable during hard fault, NMI and FAULTMASK handlers". This means that for unconfigured regions, only the privileged can access them, and the MPU is disabled during hard faults, NMI, and FAULTMASK handlers. What would happen after this configuration? The CPU is in bare-metal mode without an operating system, and it is in privileged mode. Who should it listen to?

Hello to the STM32 Community, I am trying to connect a fast TI DAC904 to a Nucleo board with H743. I am using it as a single M7 core. I have built a project with CubeMX where:Timer1 -> DMA -> FMC -> DAC904Short sine buffer in RAM-D1 and DMA as circular bufferIt works but I am getting maximum speed of 12.6 MSps.I have tried to modify the timer frequency but I am getting a limit at that speed Is there a way to make if faster?Thank you Benny  

①Fault Phenomenon: The fourth physical output core acquisition pin is faulty. Without any external connections, the voltage at the CPU pin measures around 4.3V, whereas it should normally be 0V. This also causes the operational amplifier chips connected to it to experience overvoltage. After removing the external connected components and chips, the CPU pin still has floating voltage, and the physical output core reads floating values. Replacing the external operational amplifier chips does not resolve the fault. After replacing the CPU chip, the fault is eliminated.②Fault Location: The U8 pin (pin on page 3) is damaged, causing overvoltage to the external op-amps (IC16, IC15) and itself exhibiting floating voltage, which leads to incorrect data acquisition in the physical output core. Meanwhile, the other four physical output core acquisition functions remain normal; only the PA3 channel is damaged.

Hello all, I want to connect a 3.3 V I2C based keypad with STM32U5G9J-DK1 via a carrier board on which the STM32 board sits via expansion connectors CN9 and CN10 present on it. I am using pins PG13, PG14, and PG9 for my I2C SDA, I2C SCL, and INTERRUPT, which are available as Pin No. 4, 2, and 8 respectively on CN10. The signals pass through a level shifter (TXS0104VDR) on the carrier board for conversion between 1.8 V signals at the STM32 end and 3.3 V signals at the keypad end. These lines are also connected with external pull up resistors as indicated in images attached. All the capacitors between the signal lines and GND have been unmounted. Also, 0 Ohm resistors (R27, R28, and R29 have been unmounted). During operation, STM32 can't detect any I2C device connected whereas the keypad seems to work perfectly when used in a different setup. Upon further investigation, it appears that all the three pins have become unresponsive, even when the board is used standalone, disengaged from th

Could you please tell me how many CAN interfaces are there in STM32H723? I asked the AI, and the AI said there are 2. But when I configured it using Cubemx, I found there are 3. Help me, please!

Hi everyone,I have developed a custom USB DFU HOST class, which I use to update other stm over the usb.I was first on the F4 series, but now switched to the G0 series because of this issuehttps://community.st.com/t5/stm32-mcus-embedded-software/usb-writepacket-stuck-in-infinite-loop/td-p/870532I am using external bypass clock, but the update worked also on HSI just fine.These are all the bootloader versions and the chips I was able to update without any issues:14.4 H573I-DK9.2   L562RET69.0   F446ZE-NUCLEO3.3   F207ZG-NUCLEOBut when I try to update the H745I-DISCO or the H743, the update does not work.I checked the bootloader version on the H745I-DISCO and it's 9.0, which is the same version as F446ZE-NUCLEO which I update without any issues.The update process to update H745I-DISCO worked one in 100 or 200 tries.I have tried messing with timings, clocks, adding prints in the interrupt to slow things down (I know that it's a bad practice), an

I'm trying to use the internal CRC calculation unit in the STM32H7 FLASH controller via the HAL_FLASHEx_ComputeCRC() api. I've finally started getting crc32 values returned but can't match them against any common algorithms ... reviewing AN5507 implies it is using poly 0x4c11db7 and maybe initial value 0 ?I had thought it would match the CRC peripheral defaults but this is not the case.Part of my issue may be address bounds, it seems to be inclusive of the start/end addresses so end address is 1 less (though RM indicates bottom 2 bits can't be set so -1,-2,-3 gives the same results). Finally got consistent return values with different burst lengths but still can't matching other algorithms such as those generated by srec_cat with the -STM32 filter.I've seen some comments indicating this may not work at all but the latest errata has nothing about it (STM32H725)It feels like CRC checking of FLASH memory is exactly what this was supposed to be used for but I'm surprised it isn't better do

Currently I am working on STM32H7S78-DK board, In that I am trying to save some data in External flash which will be read over every boot up but while trying to write in specific memory location it will hit to hard fault. I would like to seek clarification regarding write and erase operations on external NOR flash while operating in XIP (memory-mapped) mode on the STM32H7S78-DK.Current Setup:The application is executed directly from external NOR flash (mapped at 0x70000000 via XSPI).Memory-mapped (XIP) mode is enabled for instruction execution.Read operations from external flash are working as expected.Observed Issue:During erase/write operations, the system encounters hangs and eventually enters a Hard Fault condition.Understanding of the Issue:Erase/program operations require switching the XSPI interface from memory-mapped mode to indirect/command mode.During this transition:External flash is not available for instruction fetch.The CPU continues attempting to execute code from the sa

Dear people,   I use these little square pins and headers (see image), to obtain access to the contacts of CN11 / CN12 of Nucleo Boards, e.g. H723ZG, or F756ZG?. However these are impractical, because movement or vibration might lead to interruptions. And I want to avoid soldering, for specific reasons. Ideally would be some sort of connector that makes good electrical contact and can be coupled/decoupled easily. Can someone suggest an efficient and ergonomic solution?   Thank you  

Dear all,I'm unable to connect via SWD to my STM32F103C8T6. What ever I try I get no target found with STM32CubeProgrammer or ST-LINK Utility (I have tried all combinations at slow and high speeds). - device is virgin- BOOT0 is low- NRST unconnected (shows 3V3) and connected/removed while testing- Connections go through from ST-Link to STM32 pins- 30 Ohm and 0 Ohm tested for SWCLK and SWDIO (GND and 3V3 connection to ST-Link with no resistor)- Correct mapping of ST-LINK pins to STM32 checked multiple times- There are no obvious shorts between any of the paths- 3V3 is stable and GND closed- The ST-Link was tested with a "blue pill" board with the same STM32 on it and it worked flawlessly I have also tried:- Cutting the path to the esternal 16MHz crystal curcuit- Connecting/Disconnecting VCC- Soldered a new STM32 onto the board I am currently running out of ideas, I think there is either a fault in the PCB design that damages the MCU or prevents booting or maybe some confi

Hello,after setup SPI1 and setting CSTART=1, I expected that SPI is send immidiatly on bus.(I toogled PE00 with CSTART=1)I couldn't find some that explains that behaviour. It behave  the same, if I use DMA or writing directly to TXDR.Do you have an idea ?My testcode. SPI1->IFCR = 0xFFFF; // Clear all flags MODIFY_REG(SPI1->CR2, SPI_CR2_TSIZE, BufferSize); SPI1->CR1 |= (SPI_CR1_SPE); SPI1->CR1 |= SPI_CR1_CSTART; GPIOE->ODR &= ~(1 << 0); for (u32 i = 0; i < BufferSize; i++) { LL_SPI_TransmitData8(SPI1, pBuffer[i]); }CPU is set to 160Mhz and SPI Prescaler is 256 

Hello,I am trying to setup the BLE stack on my custom board without LSE using a STM32WB55CEU6. I have multiple boards on hand, on the first one, appe_Tl_init(); worked fine and I got to the BLE stack initialization code. However BLE never worked due to using a 16Mhz crystal. Before I had the chance to change out the crystal, the MCU bricked due to unrelated flash mistake.Now on the second board, I switched out the crystal to a proper 32Mhz one, unfortunately, despite flashing the wireless stack the same way, the wireless stack seems to instantly hard fault. Everything else, including USB (which relies on tight clock) work on the new 32Mhz crystal, I even soldered back the 16Mhz crystal temporarily, and it did not fix the hard fault. I flashed the most recent FUS and wireless stack, v2.2.0.0 and v1.24.0.3 respectively. I tried with ble_light, ble_full and ble_full_extended, all hard fault CPU2.So, within MX_APPE_Init(), during the call TL_Enable(), CPU2 hard faults. The contents of SRAM

Setup: STM32F411RE + STM32CubeIDE + X-CUBE-AZRTOS-F4 v1.1.0 + TIM4 as HALtimebase Problem: Thread runs once, toggles LED, then hangs inside tx_thread_sleep(50) and never wakes up. Debugger shows:System Timer thread → State: SUSPENDED, Run Count: 0Thread 1 → State: SLEEP, Run Count: 1 System Timer never runs, so sleeping threads never wake up.Question: Why is the System Timer thread never getting scheduled? Any known issues with X-CUBE-AZRTOS-F4 v1.1.0?

Hi,We are running a crypto key generation library on both an STM32G474 (170MHz) and an STM32H563 (240MHz).Over about 80 runs, the average generation time is around 12 seconds for the H5 and 38 seconds for the G4.These times are fine for our application (although faster would be better) but I am curious why the G4 is over 3 times slower as I would have expected something more like 40% longer generation times.The arithmetic part of the library uses some assembler functions for long multiplications and, for both processors, these seem to have picked a section for "Armv6-M (or later) with DSP Instruction Set Extensions."The compiler flags being used are listed here. The repeated sections are because I still haven't really figured out how cmake is generating them but I believe the relevant differences are:-mcpu= cortex-m4 or cortex-m33-mfpu= fpv4-sp-d16 or fpv5-sp-d16compile C with /usr/bin/arm-none-eabi-gcc__VERSION__ "14.2.1 20241119"G4 Flags:C_FLAGS = -mcpu=cortex-m4 -mfloat-abi=hard -mf

  Hello everyone, I’m facing an issue while trying to debug my project custom_for_stm32f103c8t6 in STM32CubeIDE. When I launch the debug session, I get the following error message: Error in final launch sequence:Failed to start GDB server What I’ve tried so far: Installed ST-LINK driver (STSW-LINK009). Changed USB cable and port. Reset the STM32F103C8T6 board. Interestingly, I can still flash the firmware successfully using STM32CubeProgrammer, but debugging through STM32CubeIDE fails with the error above. Unfortunately, the error still persists. Has anyone encountered this problem before and found a solution? Any guidance would be greatly appreciated. Thank you in advance!    

We have an issue with a scroll list widget, on the hardware when you touch and scroll to a point, stop then lift your finger of the display the list accelerates  in the direction it was dragged in initially. This behaviour is not seen the simulator. In the designer, we have scrollable container with a scroll list inside it. Setting animation has no effect, easing option = In, Swipe Acc = 0, Drag Acc = 0, Overshoot % = 0. we have tried adjusting the both Acc without any effect.The list has up to 50 entries.scroll list void listMenuView::setupScreen() { menuItems = presenter->getListItermParams(); scrollList1.setItemSelectedCallback(scrollListItemSelectedCallback); params = static_cast<CONTROL_VERTICAL_MENU_T *>(presenter->getWidgetParams()); menuHeader1.params = &params->menuHeader; menuHeader1.updateConfigs(); menuHeader1.setEventListener(this); messageBox1.setEventListener(this); // set the size of the scroll list based on the number of items

I am working on a custom board with STM32F103CBT6TR. Initially, flashing the code resulted in a Hard Fault error, but now it consistently enters a SIGTRAP even after removing all breakpoints. Additionally, the GPIO pins are not toggling as expected. The code is attached as notepad file for reference. Can someone give a solution to this, thank you. 

I've got some trouble with the CRC unit in an STM32L475.At first, I got wrong CRC results, but then it dawned on me that the compiled code didn't force only 8 bits at a time into CRC->DR. So I added what I've used elsewhere, to force the compiler to store only 8 bits in a 32-bit register.*(__IO uint8_t *)(CRC->DR) = Temp;Temp is a uint8_t variable. Below, it certainly looks like a single byte is transferred to CRC-DR (strb instruction). *(__IO uint8_t *)(CRC->DR) = Temp; 80013ea: 683b ldr r3, [r7, #0] 80013ec: 7018 strb r0, [r3, #0]However, after I modified my code that way, it would seem that nothing is calculated at all. No matter how many (non-zero) bytes I throw into CRC->DR, the output just stays at 0.If I revert back toCRC->DR = Temp;at least I get something, albeit an incorrect value as soon as I enter more than one byte.I initialise the CRC unit like this: CRC->POL = 0x04C11DB7; CRC->INIT = 0; CRC->CR = CRC_CR_RESET;Is there something blatantly obv

I’m choosing a microcontroller for a new STM32 design and I’d appreciate some recommendations.I don’t have particular requirements for compute performance, memory size, or ultra‑low power — just solid peripheral support and a Nucleo board available for development. Required peripherals: 1 × FDCAN (CAN FD) 3 × SPI (in practice only 1 SPI with multiple CS likely) 3 × I2C  Constraints: Prefer MCU in LQFP / QFN (no BGA) Compact (48 pins)  Development on a Nucleo board  I’ve looked at parts like STM32C552VET6 and STM32L552CCT6 as potential targets, but I can’t find a dedicated Nucleo board for them.   Any suggestion? thank you,   best regards,   Gianluca

Hi,I am using a STM32WB5MMGH6 BLE module and for some reason HAL_IncTick() is not being called. It is baffling because it was working perfectly well when I was recently working on it before switching to another project for a week.I stripped the project down to almost nothing and placed a HAL_Delay() right after the CubeMX-generated initialization code in main(). So no custom code could do anything to affect that behavior (like turning off interrupts etc). However, the delay never completes.The code is stuck inside the while loop in HAL_Delay() because HAL_IncTick() is never being called (i.e. the system tick is not incrementing) so the HAL_GetTick() always returns 0. __weak void HAL_Delay(uint32_t Delay) { uint32_t tickstart = HAL_GetTick(); uint32_t wait = Delay; /* Add a freq to guarantee minimum wait */ if (wait < HAL_MAX_DELAY) { wait += (uint32_t)(uwTickFreq); } while ((HAL_GetTick() - tickstart) < wait) { } } The Timebase Source is set to SysTick

Hi,Observed ProblemHAL_ADC_Start_DMA() returns HAL_OK, TIM2 starts, ADC begins converting (confirmed via ADC_ISR in debugger), but HPDMA1 Channel 0 immediately raises a DTE (Data Transfer Error), triggering the error callback. EnvironmentMCU: STM32N657X0HXQBoot mode: Two-stage boot — FSBL + XIP Application (external flash via XSPI2, mapped at 0x70100400)Toolchain: STM32CubeIDE / GCCHAL: STM32CubeN6 (latest)Security mode: Full Secure — all code runs in Secure Privileged mode, no NonSecure worldProject DescriptionThis is a minimal reproduction project containing only:ADC1 — single channel (PA8 / INP5), triggered by TIM2 TRGO, DMA circular modeHPDMA1 Channel 0 — linked-list circular mode, PERIPH_TO_MEMORY, ADC1 → AXISRAM2TIM2 — provides ADC trigger at fixed rate (Period=799, no prescaler)No ETH, no LwIP, no NPU — deliberately stripped down to isolate the DMA issue.Memory Layout (Linker Script)  ROM (XIP) : 0x70100400, 511K — code in external flashRAM (FLEXRAM) : 0x34000000,

Hi Support,I am unfamiliar with this project structure where the generated project contains separate boot/ and appli/ directories. I created the project using STM32CubeMX with the CMake toolchain selected, and noticed that two separate .elf files are produced after building.I am unsure which of these should be used when flashing the board using STM32CubeProgrammer. Currently, I am able to successfully flash the device using the .elf located in the /boot/ build directory, but I cannot flash the .elf located in /appli/.Could you clarify the purpose of the boot/ and appli/ directories and which firmware image is intended to be flashed? Additionally, is there a way to generate a more traditional single-application project structure (i.e., without separate boot and application directories) when targeting the STM32H7S3L8?Any guidance or suggestions would be greatly appreciated.

Post updated by a ST moderator: 1- Title translated from Chinese to English. 2- Used </> button for the code. I am attempting to transplant the latest FreeRTOS kernel program on the basis of the project generated by CubeMX. When FreeRTOS uses HSI, there is no problem and it runs normally. However, when using HSE, an initialization timeout occurs. Without transplanting FreeRTOS, HSE can pass the initialization normally.My approach was to incorporate the xPortSysTickHandler, xPortPendSVHandler, and vPortSVCHandler required by FreeRTOS into the three functions in the it file. Then, I found that it was the xPortSysTickHandler() within the systick_handler() that was causing the issue. After commenting it out, the HSE could be initialized normally. So, I'm asking on the forum what the reason is and if there's a way to solve it. AI is not reliable. void SysTick_Handler(void) { /* USER CODE BEGIN SysTick_IRQn 0 */ /* USER CODE END SysTick_IRQn 0 */ HAL_IncTick(); /* USER CODE BEGIN

So, when I was actually trying to work on the STM32F103CBT6TR MCU which is placed onto the custom board while I tried to toggle PA1 in it which only gave floating values then in debug, I found out it is going into Hard Fault Handler so then again I replaced them with new IC but again it is coming as same Hard Fault Handler. I also tried for pin 0 too. What can we do to solve this?

Split from How to make the FDCAN with DMA - which is solved.TL;DR: STM32s don't support DMA for CAN or FDCAN.Hi, thanks for the clarity.But, the doubt I'm having was, then how to handle that much data rate like eg.5mbps in FDCAN without any help of DMA?In my case, the CPU will be busy with doing other high priority works, so how can I handle the CAN data without the intervention of CPU.Kindly, suggest a way to resolve this. Thanks