STM32F4 Resetting itself (Nucleo 64)

[Andres Cao]

Posted on April 14, 2017 at 00:58

Hi!

I have a Nucleo64-446RE and every 5/10 minutes the board resets itself.

I'm using the Virtual COM to send data to my PC and plot it (among many other things), and when the board resets I lose the Serial connection. I need to re-open it in order to plot again. If after this reset I want to program the microcontroller I get the ''Unable to reset target'' message for which I need to unplug and replug the USB(which is also powering the board). I'm using the System Workbench for STM32.

Here's an oscilloscope picture of the NRST pin (blue), which confirms the reset. The red trace is a 3.3V pin, which shows there are no power issues. 

Can you please help me debug this reset?

As I understand, it can't be a Hard Fault because (I think) in that case the system wouldn't reset but end up in an infinite loop. I haven't implemented any of the error handlers, but I think they're implemented by default with weak attributes.

Watching the following image:

From external sources:

• Definitely I'm not pressing the reset button
• The ST-LINK could be resetting. How likely is this, why would it? Given that Virtual Com connection is lost it could be the case, since if I press the reset button the Virtual Com connection is not lost.

From internal sources:

• WWDG is not activated
• IWDG is not activated
• Red trace would prove it's not a power reset
• There's no lower-power mode being used.
• Software reset, this would be the only option. What causes a software reset?

Thank you very much in advance for all your input!

Cheers,

Andrés

[Andres Cao]

Posted on April 18, 2017 at 19:12

It's definitely something I can work around with a USB-Serial, but would prefer not to.

I powered it with an external power supply and while connected to the computer it has the same behavior. However, with the external power supply but the USB disconnected the T_NRST is not triggered. But, of course, I get no data.

I will try tomorrow with a Linux computer and see if the problem persists.

Are you sure you don't have anything on the PC side that's probing the mbed MSC drive? Windows system goes into sleep, suspend, spins down drives, screen savers, etc.

Not a 100% sure, no. I know there's no sleep, suspend, or screen savers. Regarding the MSC driver to be honest I don't know, not even how to check that. 

Thanks again!

Andrés

[Tesla DeLorean]

Posted on April 18, 2017 at 19:29

If you don't have tools to monitor bus activity or the driver stack on the PC side, the easiest test would be the USB Charger/Battery method. The board is thus powered and functional, and random resets can be checked, without anything on the PC side causing interference. Beyond OS oddities, consider AV and other software unique to your system/configuration.

If it is something on the PC side you'd need to go remedy that. ST is unlikely to review the situation without compelling proof that the ST-LINK is actually malfunctioning, which seems improbable as I've got plenty of boards that can run for days and weeks without getting randomly reset, and I'm not seeing reports here of many such failing.

[Imen.D]

Posted on April 18, 2017 at 23:57

Hi

Cao.Diego_Andres

,

I will check this case and keep you informedabout the status of the checks.

Imen

[Imen.D]

Posted on April 19, 2017 at 12:33

Hi

Cao.Diego_Andres

,

Have you tried with other board and you get the same issue?

Imen

[AvaTar]

Posted on April 19, 2017 at 12:56

I suggest to check the current drawn by your Nucleo board.

Perhaps you are at the edge, with temporary spikes (increased current draw) causes drop-outs of the power supply.

That would bring down the ST-Link part as well.

I suppose the observed, 'random' target reset initiated by the ST-Link MCU is normal startup behaviour.

I had similar issues with another board some time ago, with a LCD display attached.

It worked sometimes, and crashed randomly. Using an external power supply solved the problem.

[Andres Cao]

Posted on April 20, 2017 at 13:00

DAHMEN.IMEN

‌,

Turvey.Clive.002

I've connected the Nucleo board (the same that was having problems) to a Raspberry PI, while showing my serial port in a normal terminal.It has been running for more than 30 minutes without any trouble, previously it would crash between 4 and 5.

So either my computer (Dell XPS9550, Windows 10) is doing funny things with the USB which the ST-LINK doesn't like, or the ST-LINK and my computer can't agree on something (?).

This is definitely non-critical, although I'm still curious about what is happening.

Thank you all for the help!

Andrés

[Gregory Hancock]

Posted on April 21, 2017 at 22:26

I am seeing the same behavior with a Nucleo-32 board (P/N NUCLEO�L432KC). The board works fine and is completely stable when connected to a Lenovo ThinkStation E31 desktop running Windows 7, but it exhibits spontaneous self-reset when connected to a Dell Precision 7510 laptop running Windows 10. I have the same versions of the ST-LINK driver and utilities installed on both. I upgraded the firmware on the Nucleo board just a couple of weeks ago.

I have not yet dug into troubleshooting the problem, but I thought it worthwhile to let others know that this problem may be more widespread than initially assumed. Maybe something with Windows 10?

In my case, the ST-LINK Virtual COM port (VCP) stops displaying the Nucleo's output after the reset, but data to the Nucleo continues to flow. I have to disconnect and reconnect my terminal software (TeraTerm) for the VCP to begin displaying Nucleo serial output again.

I will post an update if I find a resolution.

[Brian Tetzlaff]

Posted on April 21, 2017 at 20:39

I am having the same problem, however it is with a different Nucleo board.  After 3 to 4 mins, the board resets.  This causes 2 things to happen.

1) If I was debugging, I would get disconnected from the debugger.

2) The TX over the STLink VCOM connection stops working until the board is powered down and brought back it up again.

This reset problem happens on both my Nucleo F767ZI and my STM32F746G-Disco board, so I do not think that it is a board problem.  I also trapped the reset cause and it shows up as an External Reset.  We scoped the NRST line and saw that it gets pulled down when the reset happens.

I am using the latest STlink USB drivers and updated the STlink firmware in the Nulceo board.  I even updated my BIOS and Laptop Drivers too.  I have the board running off of an external 5v power supply.  And I tried removing SB15 from the Nucleo board.  Nothing I have tried as been able to fix the problem.

I did a lot of tests and found out that by just having the STlink USB cable plugged into my laptop that that is enough to get the reset problem to happen.  It does not have to be used for debugging or as a power supply or even have the USB drivers installed.  All it needs to be is just connected to have the problem happen.

I found another laptop at the company that also causes the board to reset.  Oddly enough that laptop is from the same family as the one I am using.  I use a Dell Precision 3510 and the other one is a Dell Precision 7710.  The other Dell laptops at the company work just fine.  They are all older models such as a Dell Inspiron and a Dell Lattitude.

[Tesla DeLorean]

Posted on April 22, 2017 at 12:42

Try disabling the mass storage driver, the mbed firmware wants to use that to send firmware on to the STM32.

Screen savers, AV and power down options may come into play. If a USB charger works without incident then the issues is with the PC and the software running on it.

[Andres Cao]

Posted on April 22, 2017 at 14:40

If a USB charger works without incident then the issues is with the PC and the software running on it.

I agree Clive.

On the other hand, I can run my USB oscilloscope, mouse, keyboard, etc., without problems at all. So there's something else to this, specifically related to the ST-LINK. 

I wouldn't consider it chance that the 3 cases reported fail with Dell computers.