STM32F042 sometimes hans upon NVIC_SystemReset()

[Mehmet Erol]

Hi,

One out of 10/15/20 times, STM32F042 MCU in my application hangs upon NVIC_SystemReset(). Any idea on what could be the reason ? Some more info :

-BOOT0 is directly connected to ground. In CUBEMX, nothing was set for that pin.

- I removed the external pull-up on the reset line. There is only 100nF towards ground on NRST.

- Hard reset via power cycle always works.

I tried to use while(1) loop instead of NVIC_SystemReset() for IWDG to take care of the reset but it is happening with IWDG as well. It is quite unpredictable.

Edit : One final detail, as mentioned here, I tried to put  HAL_Delay(100) before the reset command and it seemed to reduce the frequency of this happening. This is really strange and I have no idea on what's going on..

[FBL]

Hello @Mehmet Erol,

Could you please confirm using Nucleo-F042K6 or a custom board? Have you tried to add debug prints to narrow down the issue?

[TDK]

Attach a debugger, see where the code is at when it "hangs". It's likely doing something.

[Mehmet Erol]

How do I do that when the chip tries to reset itself ? I thought I could not debug it when it goes into reset. 

[Mehmet Erol]

It is a custom board. See the schematic below. I use CUBEMX, STM32IDE and ST-LINK/V2 

[waclawek.jan]

NRST is connected how?

Note, that it's a bidirectional pin, and If the mcu is not able to pull it down (i.e. if it's driven actively high externally), it won't perform software reset.

JW

[TDK]

Edit debug configuration, select Download: False and select Reset: None. Then when you hit debug, it will attach without downloaded the code or resetting the chip.

You can also attach the debugger normally, hit resume, get it to the "stuck" state, and hit pause to see where it's at.

Schematic looks okay except for the crystal, pins 2+4 should be grounded.

[Mehmet Erol]

Ok I checked it with the debugger and it is actually not hanging. I was checking it through a MODBUS communication before and that interface is not working. The reason seems to be the fact that I can no longer get UART interrupts and it happens every once in a while. It basically does not go into HAL_UART_RxCpltCallback anymore. 

Any idea on why such a thing can happen only upon a soft reset ? 

As for the crystal, yes you are right but those ground pins are mostly for EMI as far as I know so I would not expect it to cause such an issue. 

[Mehmet Erol]

Following TDK's advice, I checked it with a debugger and it appears not be a reset issue. It is just that sometimes upon a soft rest, my code no longer gets RX callbacks from my UART interface. Still investigating.

[Mehmet Erol]

An update : I increased the delay before NVIC_SystemReset() to 500ms and I can no longer reproduce this. I am still very curious about how this could have an impact on my code though..