STM32F746ZG STM32F767ZI unexpected, unwanted Reset

[Joerg Wagner]

Posted on February 03, 2017 at 17:20

I use NUCLEO-F746 and NUCLEO-767, CubeMX 4.19 with FreeRTOS and LWIP.

No Watchdog, enough space for sprintf() stack behaviour and SRAM1 only.

DC power comes from a DCDC 24/5V converter, super clean, monitored by Oscilloscope.

My software performs a Reset approx. one time in an hour, but no NVIC_SystemReset command is in the code.

I adopted the project on the NUCLEO-767ZI board, same result. The board is connected

to my peripheral board for signal conditioning, every signal is isolated with a digital isolator.

A FRAM is used to keep track of the 'Reset' counts.

First I thought there are just 3 ways only to reset a controller.

Any ideas? I appreciate any help. Thank you.

[T J]

Posted on February 03, 2017 at 23:42

Power fluctuations will reset a processor.

Sdram sucks power and is noisy, that is why there is a IO Vcc and a core Vcc on these chips.

This could cause intermittent faults. This is likely to be the cause if it is a hardware fault.

More capacity and a more careful PCB track layout may be necessary.

Over heating inside will result in an inaccurate fetch from instruction memory, and the processor will do something different, usually catastrophic for your data set integrity, thereby you will crash and possibly recover and continue to crash until the heat is removed. Arm processors don't get very hot.  If you can put your finger on it, I think it is operating at the correct temperature. I read my processor temp, it is 42C in my ambient of 29C.

Error_Handler, NMI, IRQ

all interrupts must be absolutely tested.

any issue here will cause the watchdog to come in.

disable all endless loops, again watchdog reset

Power supply capacity:

I only use Unitied Chemi-Con or Nichicon Capacitors, make sure your have some decent capacity on your power lines..

like this one:  with 2.175A ripple current on my 5V rail

   UHW0J332MPD Nichicon CAP ALUM 3300UF 20% 6.3V RADIAL 10000 Hrs @ 105°C 2.175A @ 120Hz 17 mOhm

    0.197' (5.00mm)     0.394' Dia (10.00mm)     1.063' (27.00mm)     

[Tesla DeLorean]

Posted on February 04, 2017 at 01:32

Does it have a register indicating the cause/source of the reset?

Trigger the oscilloscope on the NRST pin

Also be aware that the ST-LINK can reset the target processor. You'd want to check the firmware version here because ST has fiddled with it a lot.

[Joerg Wagner]

Posted on February 07, 2017 at 18:01

Firmware is the latest one. Temperature is no object.

An extra electronic circuit monitored the NRST pin: It goes low.

When I remove '-u _sprintf_float -u _printf_float' in linker settings,

no Reset occured since 18 hours. NUCLEO-F746ZG is currently used

in industrial environment.

[T J]

Posted on February 07, 2017 at 20:41

wow, shocking result...

which compiler are you using ?

which optimization is it set to ?

can you finish this test and then put back the -u  and see if the false reset comes back...?

[Joerg Wagner]

Posted on February 07, 2017 at 22:30

OpenSTM32 Version 1.13.1.201701200843

Optimize for size (-Os)

I can reproduce it, because I found a mistype in my settings.

I wrote '-u printf_float' instead of '-u _printf_float', which does not enable float support.

But a reset does not happen immediately. Can take an hour. It's hard to investigate.

[T J]

Posted on February 07, 2017 at 22:46

is your code size close to the limit ?

Printf is a fundamental function, it cannot be faulty.

can you try different optimizations ?

MBed uses -o2

[Joerg Wagner]

Posted on February 07, 2017 at 23:56

Code ends at 0x800FD9C. Basically we are lucky to be able to process data from the machine right now, the board is connected to.

It's not a hobbyist work at home. But I will prepare another one to make some tests.

[Joerg Wagner]

Posted on February 17, 2017 at 23:03

I think I have to give up. No sprintf/printf/sscanf is in my code anymore, but unwanted resets still occur.

Sometimes you have to wait 25 hours, or sometimes just 1 hour or less. I had luck and noticed two resets while

I was looking at my status data coming from the board, so I can say 'There is no specific moment as  a reason'.

Ordered a F429ZI as a last hope. I wish I can trust the hardware. It's hard for me to believe to force a reset

with software. It will end in an infinite loop i.e., but not a hardware reset. I prevent to divide by 0, do not

use non-reentrance functions twice and so on.

[T J]

Posted on February 17, 2017 at 23:42

I had a problem on the Oscilloscope, which I thought was concerning.

The Switch mode power supply looks good until I disconnect the PC serial port.

The PC serial port was providing a good earth.

Without it, I could see 50Hz railing on the scope.

How are you tied to earth ?

The PC earth itself tends to send spikes occasionally which doesn't seem to affect my boards.

I intend to carry a 2mm thick earth beside the isolated CANBUS shielded twisted pair, to be sure.