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

[Tesla DeLorean]

Posted on April 14, 2017 at 02:28

The STM32 has a reset reason register, you should inspect that.

If it is not the power (VDDA has the POR circuit) then I start supposing the ST-LINK. what firmware do you have on that currently? Make a note of that, and then make sure you have the most up to date ST-LINK Utilities, and use that to upgrade the firmware.

[Andrei Chichak]

Posted on April 14, 2017 at 08:05

Put a memory breakpoint somewhere between the stack and the heap. I'm wondering if you're grabbing memory, over indexing an array, or blowing the stack. I'm not sure how that would manifest itself, but rule it out anyway.

Andrei

[Andres Cao]

Posted on April 14, 2017 at 13:46

Thanks Clive!

I'll check on the versions and confirm. 

I checked the schematics, I will remove the solder bridge SB12 to isolate the reset signal from the ST-LINK and check if it's indeed that. Seems to be easy to test. 

Regarding the reset register:

Reset value is not entirely clear.

I understand I should read this register and then clear it with the RMVF bit. Then after the system resets itself I should see PIN + any other flag. And if I see only PIN, then it's the ST-LINK. Does this sound correct?

I'll bring more updates on Tuesday, since my lab is closed until then.

Thanks again,

Andrés

[Andres Cao]

Posted on April 14, 2017 at 13:49

Thank you Andrei,

I'm not allocating memory dynamically, all arrays are fixed size. Also, the indexing of the arrays is also fixed, there's no array[variable] access. So that could leave blowing the stack as a possibility, I guess.

Could you elaborate on how to put this memory breakpoint that you mention?

Thanks!

Andrés

[Andrei Chichak]

Posted on April 15, 2017 at 18:45

It depends on your debugger. In eclipse, using the Memory Browser view, right click on a portion of memory between heap and stack and use 'Add Watchpoint'.

You could set up the watchpoint to halt your program on reads or writes.

How do you figure out where the heap ends? Luckily you are using static allocation of data, you are a very smart person. Have your compiler generate a 'map' file, and figure out what the highest address is for your declared variables. You should have free space above that.

Another idea is to create a variable, once again using the map file, that is allocated at the high end of the heap. Give it a known value, and periodically check to see if it still has that value. If the stack is getting blown, this 'sentinel' value might get overwritten. A memory watchpoint on that variable will halt your program and you can see where in your code the access happened.

You could run your program for some large portion of the normal time before it resets, halt, and inspect memory to see what is going on.

Andrei

[Andres Cao]

Posted on April 15, 2017 at 20:22

Andrei,

Thank you for your very detailed answer! It is a great piece of advice I had never thought of because it's the first time I'm dealing with this problem.

I will try with the easiest things to check and then move to this. I will also check this map file just for curiosity and play with the memory watchpoints. 

As soon as I found out what it is I will post it.

Thanks!

Andrés

[Tesla DeLorean]

Posted on April 15, 2017 at 20:27

Still seems more of an external issue, especially if one can eliminate watchdog or NVIC_SystemReset action. Power would be the primary one, but the NRST is connected to other things on the board that can precipitate a reset.

[Andres Cao]

Posted on April 18, 2017 at 17:25

Ok... so I think we've found it.

First step: disconnect the T_NRST from ST-LINK to NRST of the Target MCU.

So, after I did this I was still having problems, still the reset. So the T_NRST cannot be resetting the MCU. But anyway, I put a pullup to the T_NRST and registered what happenned when the MCU resets. This is the result, red trace is the NRST from the Target MCU. Blue trace is the T_NRST from the ST-LINK (50ms/div, and then a zoomed version):

Doesn't make much sense in the beginning. Looks like the ST-LINK knows beforehand that the MCU will reset. If you ''and both signals'' you will see the it has the double peak as showed in the first post. 

Inspecting the RCC_CSR register the value I was getting (after a lot of trial since the debugger stopped working so I had to do it with the LED) was 0x14000000. This means Pin Reset + Soft Reset.

So, only chance left is that they're connecting through the Serial Wire Debug. Either the ST-LINK senses a problem and then tries to reset the target MCU (which has some problem that causes a Soft Reset), or the ST-LINK is sending a Reset Command. 

I take a look at what happens with the T_NRST and the SWD Clock signal. 

When ST-LINK is trying to reset the target MCU, there's some communication going on in the SWD interface. This would confirm what was thought previously.

After this I disconnected the SWD Clock and Data I/O from the target MCU. Red is T_NRST and blue is the NRST from the MCU.

The ST-LINK tries to reset the MCU but now it has no way. It was sending a Reset command through the SWD and also using the T_NRST pin.

Good news: My code is OK.

Bad news: ST-LINK is still having problems and doing that every 3/4 minutes. This means that I'm losing the serial connection and have to reopen the port every time. Not acceptable for what I'm trying to do.

Next step? I will upgrade the firmware as suggested and try again, I wanted to find the cause before upgrading.

Thanks for your help guys! I'll soon let you know if the upgrade solves the problem or if we need someone from ST to come in and solve this.

EDIT: Updated firmware didn't solve the problem. The issue still remains.

Cheers,

Andrés

[Tesla DeLorean]

Posted on April 18, 2017 at 17:54

>>

if we need someone from ST to come in and solve this.

It is not a problem that seems prolific, you could work with the ST FAE attached to your commercial account.

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.

If you power the Nucleo from a USB Charger do these random resets occur?