6 out of 11 boards eventually reset right after starting.

[NRoth.1]

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?

[waclawek.jan]

> If you're lucky, there may be option bits which disable the BOOT0 pin.

[Uwe Bonnes · Accepted solution]

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

[NRoth.1]

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?

 

[NRoth.1]

Indeed there is! THX!! 😀

[NRoth.1]

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

[waclawek.jan]

Show how did you set the option bytes.

JW

[NRoth.1]

I deselected the nSWBOOT0.

[waclawek.jan]

JW

[lqiao.1]

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!✌�?