Help me understand why my UART communication fails

[mdiro]

Good morning, 

my product is made of 2 parts, each of which has a dedicated MCU. MCU1 is STM32L476ZG and MCU2 is STM32L4P5CG. The whole device is supplied through a wall adapter working at 24VDC. Internally,the voltage is converted to supply all the module with the required voltage. The 2 parts communicate via UART, set with a baud rate = 9600, very low. The communication is not continuous but is event-based. 

The software implementation was straight forward and all works BUT it stops working when the following happens: 

1. I upload the software in the MCUs via the ST debugger

2. I unplug the debugger (all good so far: the software works fine)

3. I unplug the supply (mains adapter) from the device and plug again. 

At this point the communication fails and UART sends only zero. This is even weirder: if I press the reset button on the board (schematic attached), the communication starts working again. Honestly, I cannot understand why the communication fails when the supply is turned off and it recovers after pressing the reset button. Any idea?

Thank you all and I am happy to add more details if needed.

[KnarfB]

few questions:

- UART sends only zero: electrial level (permanently low) or recieved '0' chars or '\0' chars or nothing?

- The code otherwise runs normal on either side?

- Are you using HAL for sending and (hopefully) permanently receiving? How?

- Full-duplex, half-duplex, simplex comm?

I would hook-up a scope (or maybe a cheap USB LA) to get more insights. Could be just bad timing after power-on.

hth

KnarfB

[mdiro]

First of all, thank you for your reply. 

1. UART sends '0' chars. 

2. Yes, the code runs normally and I am able to send the planned chars. 

3. I am using HAL. In particular I have HAL_UART_Transmit_IT for sending and HAL_UART_Receive_IT for receiving. This is what I have in the rx callback: 

 

 

void HAL_UART_RxCpltCallback(UART_HandleTypeDef * huart)
{
	new_rx = 1;
	HAL_UART_Receive_IT(huart, data_received, sizeof(data_received));

}

 

4. Full-duplex. 

[LCE]

> 1. UART sends '0' chars.

So you mean 0x30 ? That's interesting.

Anyway...

a) Are the MCU UARTs connected directly to each other?

b) As @KnarfB said: "Could be just bad timing after power-on.", what is your reset scheme after power-up?
When using more than 1 active IC, it's good to have a reset controller, so that all ICs come up at the same time.

Then, some handshake might be useful. Kinda "You there?" - "Yes" - "Let's go!" ;) 

[Karl Yamashita]

Show your code. You say the UART sends only zero but is it sending zero on both devices? Are the device(s) receiving? Maybe a little more description on each devices role?

[Bob S]

Typically there is no external pull-up on NRST, just the cap to GND.  I wonder if the resulting power-on reset pulse is too narrow for a valid reset?  That may also happen if your 3.3V supply takes too long to ramp up.  You don't show your power supply section.

Check the UART output with a scope and make sure it really is sending at 9600 baud (when you see '0' characters).

Where else does your "BOOT0" signal go?  If there is anything connected that may allow that pin to be seen as "high" during power-on, that would force the built-in bootloader to run instead of your code.

You don't have a crystal or oscillator on PH0/PH1, so what is your clock source?

[mdiro]

Thank you for your reply. 

Unfortunately this happens even if I don't pull up the NRST pin, so if I desolder the 10k resistor. Here you go the full overview of the MCU:

The BOOT0 signal actually doesn't go anywhere else. It is only pulled down. 

About the clock, I use the internal source.

 

 

[KnarfB]

As @LCE said, you're receiving a '0' which has a non-trivial bit pattern. So, the comm is probably not the root cause of the evil. I have no idea what '0' means in your system and what you expected instead. Try sending a fixed byte pattern by stripped-down firmware. Or add a 5s delay early at the transmitter side.

hth

KnarfB