STM32L431KC hangs on reset
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2025-04-28 2:43 AM
I am working on a custom board and I have noticed that whenever the device resets, it becomes unresponsive.
The reset causes that hang the microcontroller:
- Calling NVIC_SystemReset from firmware
- Having firmware stuck and receiving a signal from IWDG
- Manually grounding the NRST pin.
The debugger shows that the program starts running in a lop at addresses 0x1FFF2XXX, which would be a RAM stack, I suppose?..
My FW memory map looks like this:
MEMORY
{
RAM (xrw) : ORIGIN = 0x20000000, LENGTH = 64K
RAM2 (xrw) : ORIGIN = 0x10000000, LENGTH = 16K
BOOT (rx) : ORIGIN = 0x08000000, LENGTH = __boot_size
FLASH (rx) : ORIGIN = 0x08000000+LENGTH(BOOT), LENGTH = __program_size
FLASH2 (rx) : ORIGIN = ORIGIN(FLASH)+LENGTH(FLASH), LENGTH = __program_size
DATA (rx) : ORIGIN = ORIGIN(FLASH2)+LENGTH(FLASH2), LENGTH = __data_size
}
My USER_VECT_TAB_ADDRESS is defined and VECT_TAB_OFFSET is non-zero due to isr_vector not being at the beginning of the FLASH region.
So far I tried downloading a dummy firmware with only USART and IWDG enabled, with no custom remapping of memory - the issue persists. At the moment I cannot ground the NRST pin directly to see what happens, but grounding the external jumper input that is supposedly directly connected to the NRST pin also renders the firmware unresponsive.
Is there anything in particular I can do to pinpoint the problem? I don't currently have the electric scheme of the board to check how NRST is connected, but I wondered if I can do some more testing to see if the firmware could be at fault.
Solved! Go to Solution.
- Labels:
-
STM32L4 series
Accepted Solutions
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2025-04-28 6:24 AM - edited ‎2025-04-28 7:40 AM
All chips have a system bootloader and typically having BOOT0 not grounded during reset causes it to jump there. That would explain your symptoms. Look in AN2606 for other reasons why it could be jumping there on reset other than BOOT0 not being grounded.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2025-04-28 5:30 AM
> 0x1FFF2XXX
Indicates it's in the bootloader. Ensure BOOT0 is grounded.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2025-04-28 6:08 AM
Yes, BOOT0 seems to be grounded. This wouldn't explain the case with the dummy firmware, because it didn't have a bootloader.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2025-04-28 6:24 AM - edited ‎2025-04-28 7:40 AM
All chips have a system bootloader and typically having BOOT0 not grounded during reset causes it to jump there. That would explain your symptoms. Look in AN2606 for other reasons why it could be jumping there on reset other than BOOT0 not being grounded.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2025-04-28 7:06 AM
Thank you, you were exactly right! I had nBoot0_SW as 1 and it triggered the pattern 16 described in AN2606. Now the device seem to reset as expected.
