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?

[LCE]

Hardware checks:

• voltage supplies: value, ripple, ...
• soldering of BGA, reliable source? testpoints?
• HSE source / oscillator + caps
• NRST pin
• BOOT pins
• ... and you got the right STM32? ;)

Firmware:

• Systick settings, interrupt priority
• any changes due to updated / new HAL libs
• BOR / Watchdog stuff

[waclawek.jan]

This may be one of those cases where the system memory remains mapped at 0x00000000, maybe as consequence of "empty flash bootloader entry" mechanism or improperly connected BOOT0 pin.

JW

[NRoth.1]

@Community member​ 

Thx for your input and your check list.

• Supplied at 3.3 V it does have a ripple of 22 mV. Voltage drops due to certain triggered processes can be seen making the voltage drope about 80 mV.
• the uC (or these boards respectively) is soldered by maschine by a professional assembler (made in Switzerland). How ever, I questioned its process and its propability of failure, but so far not received any answer (asked 24h ago, so I give them little more time). But I would say that this can be excluded.
• HSE/Oscillator: I have a 24 MHz external cristal oscilator (FA-128 24.0000MF10Z-W3) that returns a beautiful 0.8 V sine wave.
• The NRST pin is connected to a 100 nF cap to GND, open drain output of MCP1316M (i.e. voltage supervisor) and to a button. The voltage supervisor will release the reset line as soon the supply voltage goes above 2.9 V (I have removed this component to make sure that it's not this one who triggers the reset, but it didn't change its behavior).
• The boot pin is floating. Checking AN2606 having BOOT0 floating seems to be a pretty bad idea!(?) How ever, the error patterns I have don't seem to be related to this, eventually I'm able to execute own code (at least a tiny bit of it), whereas the BOOT0 either make it execute code from Bank 1 or 2 or keeping the uC in continuing bootloader execution.
• YES :face_with_tears_of_joy: is the correct one (it works on 5 boards flawlessly, and its not even a different batch of uC)

Firmware:

I have programmed the same firmware on all 11 boards. As a firmware is by definition perfect, thus doesn't behave differently if the hardware is the same I would have excluded any wrong doing in the firmware and thus in its configurations. However...

• Systick,... (?) not set anything specific (can't even find any setting in the MX-Cube that is called like that!?)
• update/new HAL libs => they would behave the same on all boards.
• Neither IWDG nor WWDG are activated

...

phu, well yeah,...

[Uwe Bonnes]

"HSE/Oscillator: I have a 24 MHz external cristal oscilator (FA-128 24.0000MF10Z-W3) that returns a beautiful 0.8 V sine wave."

Datasheet 6.3.7 External clock source characteristics requires max 0.3 to min 0.7 VDDIO for HSE. I do not know your VDDIO, but 0.8 V sine wave seems also not good.

[NRoth.1]

Ok, I measured with AC-coppling activated. Using DC-coppling shows that it oscilate between 1.1 V and 1.9 V. As my VDDIO is 3V3 it actually remains outside specs. However, even my good boards don't have more. Additionally, (by mistake) I used so far the internal oscillator as I forgot to activate the external clock in my simplified firmware.

Thus, it has to be checked but it is unfotunatelly still not the cause of the problem.

[NRoth.1]

@Community member​ 

thx also for your input. This made me check AN2606 and thinking of whats happening if this pin remains floating (which it does, it's not connected anywhere). How ever, as certain boards work reliably and certain reliably not, would fit quite well into this pattern. But would I then be able to debug a single line of code at all? So far, trying to debug it eventually works for a few lines of code until I reach the above described code section (I can provide further details to this if required).

So, somehow yes, but also no. Having it floating I understand that this has to be corrected (pulled up or down)(true?).

... eventually I need anything to be certain what the cause is before I ordere an other batch super expensive boards.

? :dizzy_face:

[waclawek.jan]

> The boot pin is floating

That is the cause of your problem.

> ... eventually I need anything to be certain what the cause is before I ordere an other batch super expensive boards.

Fix it on the existing boards. If you're lucky, there may be option bits which disable the BOOT0 pin. I don't use the 'L4+.

JW

[LCE]

One more vote for the BOOT pin!

"Floating" is in general a bad idea for system-determining pins!

Might be a coin toss...

As so many threads here show.

[NRoth.1]

Hehe, "UN"fortuantelly its a 169 pin BGA :> Nope, I made already many electro-surgical intervention to inner layers, but I don't think so that I will be able or nearly successful to get to that pin from the other side.

For sure this is an issue. And it (maybe) explains the issue I have, when starting up the boards that actually work (i.e. when powering it, even with having a voltage supervisor that releases the reset pin not before the voltage reaches 2.9 V, I have to pull down the reset line manually with the attached reset button).

 

But how would you explain, that I still can run the debugger and run a few lines of codes? I mean, now having this pin floating the uC eventually will detect it as either being "high" or "low". Consequently I would either be able to run it fully functionally and maybe when turning it on a second time it wouldn't work at all, as the BOOT0 eventually makes it decide where to search for the program to run. Wouldn't you agree?

Sorry for insist for further explanation and not simply check that first. The problem is, that I'm unable to rework that on the current board (as visualised above) to check if that helps. I will have to order a new design having this BOOT0 fixed. But as this is going to be expensive in any case, I would want to find a plausible answer to all symtoms before spending the next batch of money. I hope you understand.

[waclawek.jan]

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

[NRoth.1]

Indeed there is! THX!! :grinning_face:

[Uwe Bonnes]

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, 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

[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?