What could go wrong when connecting UARTto MCUs from other vendors and running differentstack?

Mbed OS
1

Hi,

The problem I am facing is quite weird but seems real. When I connect STM32F429ZI to a radio we developed around CC1310 from TI via UART, I noticed that after flashing new firmware into STM32F429ZI or a cold start, I have to reset CC1310 to get UART communication between those two, specifically, sending data from STM32F429 to CC1310 but not the other way around, to work.

After much hassle, the problem is deemed as a compatibility issue. I was able to reproduce the problem with following test setup:
STM32F091RC, periodically sends data out of UART, and expects receiving the whatever it sends out
CC1310, flashed with uart echo example from reference documentation. It sends back whatever it receives.
UART pins and GND are connected with short wires directly.

After flashing firmware into STM32F091RC, I will have to reset CC1310 to get such setup to work.

However, I didn’t observe such problem between MSP430 and CC1310 both of which are from the same vendor TI.

I am under the impression that UART is an ancient and very robust interface, did I miss anything when connecting those two MCUs?

I reported the problem on TI’s support forum, but also want to start a thread here, just in case there is something particular about how UART is setup by Mbed on STM32 MCUs.

Thanks.

2

The problem was tracked down to glitch on UART RX line on CC1310. When STM32Fxxx with Mbed resets. I assume RX line is briefly pulled down therefore CC1310 thinks some data is going to be transmitted, while there is no actual data. Such glitch was not properly handled by either CC1310 hardware, driver, or our application code, therefore causing said problems.

3

Hello,

Can’t it be related to this? STM32 : full GPIO reset during mbed init.

BR, Jan

4

If all GPIO pins are reset, it is possible the pin on STM32 that is connected to UART RX pin is pulled low. What will happen if this full reset is turned off? Will all pins GPIO/UART/I2C etc. remain what they were configured before until they are configured by mbed code otherwise? If that is the case, turning this feature off should address the issue I had.

But on the other hand, I think the issue I ran into should be better addressed on CC1310 side. I have 3 other 3 other ICs that are connected to STM32F429ZI, none of them except CC1310 had this problem.