6 out of 11 boards eventually reset right after starting.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2022-11-07 07:20 AM
I have 11 boards of our prototype with the STM32L4A6AGI6 (i.e. 169 BGA) assembled. 5 of them work fine. The other 6 eventually loose debugging connection. It doesn't happen immediatelly i.e. I'm still able to run a few lines of code but then it resets unrecoverable for the debug session (i.e. I have to restart the entire debug session. Soft reset doesn't work).
I can also measure the NRST (Pin H3) line that is pulled down caused by any internal mechanism (Unhandled interrupt?).
To investigate what line of code is causing the eventually occuring reset I started to place a "while(1);" and checked, if I still can pause and then run again without the debbugger loosing its connection.
This lead me to the following code section:
core_cm4.h
SysTick->CTRL = SysTick_CTRL_CLKSOURCE_Msk |
SysTick_CTRL_TICKINT_Msk |
SysTick_CTRL_ENABLE_Msk;
Removing the "SysTick_CTRL_TICKINT_Msk" my "while(1);" after that line will continue to run without loosing debugging connection. Putting it back again I reach the "while(1);" but eventually it will break.
Now, this may still not be the root of cause. Starting a debugging session and pressing the soft reset button before I even run the program also makes the debugging session crash.
And just to mention again, it works on 5 boards. I.e. it can't really be a firmware issue. But what hardware failure could cause this issue with the above mentioned on the other 6 boards where the error pattern are all the same?
I do have about 10 years experience in the embedded environment dealing with uC quite a lot. But such a constellation I never faced before and causing my brain to blow up soon :face_with_steam_from_nose:.
Any one that may have an idea what is causeing that issue?
Solved! Go to Solution.
- Labels:
-
STM32L4 Series
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2022-11-10 07:44 AM
> If you're lucky, there may be option bits which disable the BOOT0 pin.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2022-11-10 12:13 PM
You are lucky:
it 27 nBOOT0: nBOOT0 option bit (this bit is reserved for STM32L47x/L48x devices)
0: nBOOT0 = 0
1: nBOOT0 = 1
Bit 26 nSWBOOT0: Software BOOT0 (this bit is reserved for STM32L47x/L48x devices)
0: BOOT0 taken from the option bit nBOOT0
1: BOOT0 taken from PH3/BOOT0 pin
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2022-11-11 12:57 AM
Indeed I'm lucky (even I have a STM32L4A6 ;))! Yes now I also found this option and it is the solution for one part of my faulty board.
First issue solved, thank you very much! But as assumed, its for sure important to set, but it's not the very issue.
Followup: As the above solution actually fixed 5 out of 6 I stop it right here. As it happens I used exactly that one that still doesn't work. However, due to the symptoms I got little surpirsed that the BOOT0 issue solved all of it for the other 5 boards. And the IWDG issue only remains for the one board. But "one is none", consequently I accept this issue as resolved.
Now, lets continue.
What works now is, that it won't break my debug session anymore when a reset is caused for any reason. However, eventually the system still resets after a few milliseconds.
Using the approach of https://stackoverflow.com/questions/34196663/stm32-how-to-get-last-reset-status
to check the reset cause showed me that these permanent resets are caused by the independent watchdog (IWDG). But this shouldn't be possible as it is not activated.
?? Any explanation for this?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2022-11-11 01:11 AM
Indeed there is! THX!! :grinning_face:
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2022-11-11 01:13 AM
Indeed, THX!!
So I also found this one, may be helpful as well.
https://community.st.com/s/question/0D50X00009XkWQwSAN/use-ph3-pin-as-gpio-instead-of-boot0
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2022-11-11 02:24 AM
Show how did you set the option bytes.
JW
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2022-11-11 03:56 AM
I deselected the nSWBOOT0.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2022-11-11 04:21 AM
JW
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2022-12-03 06:13 AM
Hi Buddy!
I think I fixed this problem !!! it takes me whole day trying to fix it !!!
​
In my case I create one project in cubemx without any configuration. this code run in to HAL_Init() and system get RESET !!!
​
you can open the file system_stm32fxxxxx.c file (in my case is system_stm32f4xx.c), find this comment:
"Note: Following vector table addresses must be defined in line with linker
configuration."
​
and then uncomment the following line.
#define USER_VECT_TAB_ADDRESS
force SystemInit function to reset SCB->VTOR vector address.
rebuild & run, enjoy!✌�?
- « Previous
-
- 1
- 2
- Next »