STM32C031 Reseting after receiving data on UART

[gabrielCermob]

Hello, I'm having problems with a simple task: receive blocks of data from UART. The blocks are sequences of 1-300 bytes, that are receiveid with a 1 second interval. The value is stored in one buffer of 350 bytes.

When I send a big block of 270 bytes after other blocks(of 60 bytes by example) in that 1s interval, the Stm32 RESETS! But if the interval is longer, like 5 seconds, it doesn't reset and receive the data correctly. 

I tried with pooling and interruption, the result is the same. I'm using 115200 baud. Lowering the baud rate also reduces the interval that doesn't cause a reset, but I can't use this solution.

WatchDog is already disabled. By this moment, the code doesn't do anything more.

[Andrew Neil]

Welcome to the forum.

Please see  How to write your question to maximize your chances to find a solution for best results.

Please show the relevant code - see: How to insert source code.

[TDK]

There is no direct link between receiving UART and resetting the chip. The reason has to be something specific to your code or hardware.

How do you know it's getting reset?

Read the flags in RCC_CSR2 on startup to determine the cause of the reset.

[gabrielCermob]

Hello! I will post some images of the signals.

In the beggining of the code, the STM sends a 9 bytes message once. After, it waits for blocks of bytes and reply the messages with a two byte response. Just that.

In the first picture, the first message received constains 270 bytes, and is correctly received (I checked in debug). Some more messages are received and the first one is repeated again in the end with a delay of 5,3s, and no problem occured.

In the second picture, it's exactly the same situation, but the delay of the last message is smaller. And the STM replies with the 9 bytes initial message, that could only occur after a reset.

Capture WITHOUT ErrorCapture WITH Error

I also checked the RCC_CSR2 after the resets(it's in the initial message), and the value is: 0x04000000. Indicating  Bit 26 PINRSTF: Pin or other system reset flag

MCU Model: STM32C031G6U6

Environment: CubeIDE
Main.c attached

[gbm]

There is no check for buffer overflow in Rx callback.

[TDK]

Code seems fine.

If NRST is going low as indicated by the reset flag, perhaps a board power issue, or bad decoupling. Can you share your schematic? If you are missing a 0.1 uF cap on NRST, you can get parasitic resets, especially if there's a long trace on that pin.

Consider monitoring the NRST line in analog mode, and maybe VDD as well. You should NRST go low. VDD should be fine since PWRRSTF is not getting set.

[Ozone]

Either insufficient power (perhaps due to hardware problems), strong EMI interference with the UART signal, or your code has a watchdog activated.

I very much suspect you talk about a custom design board here.
Try a commercial one like a matching Nucleo.

[Andrew Neil]

---

@Ozone wrote:

strong EMI interference 

---

+1

@gabrielCermob So, as well as your board, you need to give details of the environment in which it is operating.

Some good, clear photos may help.

How to write your question to maximize your chances to find a solution

[Ozone]

Not to forget, how exactly the "UART connection" is made, and which components are involved.
Because "UART" usually implies RS232, which in turns allows for -15V...+15V signals.
Notwithstanding the fact that the standard requires >= |3V| as proper level, which means the usual USB-serial adapters with 3.3V or 5V levels are compliant, but not sufficient in every case.

And larger currents through serial GND connection can easily upend a low-power device like a C03x, and cause brown-outs.

[gabrielCermob · Accepted solution]

Hello again, I found the solution!! Thanks to everyone!

I was using a custom board for the C031G6U6 that was connected to the Nucleo's St-Link, board model MB1136. The 3V3 power comes from the Nucleo(connection made under the board), and the embedded MCU is disabled by the JP6. 

Original connection

All pins were connected as described on the CN4 documentation.

CN4 Pins

It was discovered that disconnecting the NRST pin from the Nucleo board eliminates the problem!

I don't know why but, that's it. The custom board seems to be ok, it already had the 100nF cap.