Serial telemetry issues on STM32F051

[Vuk-SFL]

Occured on STM32F051 platform.

4 ESCs share common UART line to send telemetry to Pixracer FMUv4 flight controller. Flight controller controls ESCs via DSHOT600 and periodically requests telemetry packet.

2 types of problems noticed that occur from time to time:

• After system power up telemetry data is not available until reboot. ESCs respond properly to DSHOT commands for speed.
• Sometimes in middle of operaiton one of ESCs stop sendign telemetry data until rebooted.

Note: By reboot I mean re-enabling DSHOT signal to force AM32 to go to bootloader and back to am32 firmware.

Did anyone else had similar problems?

Since rebooting was fixing problem I wanted to investigate serial telemetry source code

From send_telem_DMA method I see order of operations is:

1. enable UART Tx (set USART direction to TX only)
2. set DMA data length
3. enable DMA requests for UART Tx
4. enable DMA channel
5. disable UART Tx (set USART direction to RX only)

Is there any reason why UART Tx is disabled right after DMA channel is enabled? This looks like potential problem if TX is disabled before DMA transfer and message generation is done? Would it make more sense to do that step in USART interrupt once transfer is complete (TC flag check in interrupt routine) in same manner how DMA channel is disabled in its own interrupt?

[AlkaMotors]

Yes this is correct operation. Make sure you do not have 30ms telemetry also on in the config tool. This has been the only time telemetry has stopped for people.

[Vuk-SFL]

Checked that, 30ms telemetry configuration is off.

Problem is that this happens only from time to time. It is not always present issue.

[AlkaMotors]

I have had the telemetry running for days before with bf fc's. I have not seen it stop even after 100 or more continuous hours. Are you sure the telemetry request isn't stopping? I will look into this a little deeper. We had one report of it stopping before with ardupilot but it was because both interval telemetry and dshot telemetry were being used.

[Vuk-SFL]

Here is more background about system. Maybe it can be useful to clarify conditions under which issue occurred.

Custom board Flight controller Unit (FCU) with FMUv4 running PX4. it controls 4 ESCs and has common serial telemetry line used between all 4 ESCs, telemetry requests issued one by one to avoid conflict on TX line.

For years we were using BLHEli32 ESCs but yew months ago we switched to using AM32 on STM32F051 MCU (v2.8 of firmware, I didn't see anything changed regarding telemetry since that version).
Signal is given as DSHOT600 and FCU part of SW or interface didn't change.

Issue happened on several different systems which are turned on almost 24/7 for months (reset once a day), each one of them executing few thousand flights.

On some UAVs issue can happen once per week, on others every few weeks. So it is quite rare issue but annoying when numbers scale up and also very hard to catch and debug.

When it occurs in flight, one of ESC telemetries just stops sending data, it is still running control properly (SIGNAL is applied and speed is controlled). We noticed that reseting firmware (both on FCU and ESC) recovers it. This is why I started investigating AM32 FW part since we didnt have issue with previous ESC FW.

What pointed me out to send_telem_DMA problems is how TX is disabled.

In reference manual for STM32051 (https://www.st.com/resource/en/reference_manual/rm0091-stm32f0x1stm32f0x2stm32f0x8-advanced-armbased-32bit-mcus-stmicroelectronics.pdf) section 27.5.15 USART continuous communication in DMA mode there is note:

In transmission mode, once the DMA has written all the data to be transmitted (the TCIF flag
is set in the DMA_ISR register), the TC flag can be monitored to make sure that the USART
communication is complete. This is required to avoid corrupting the last transmission before
disabling the USART or entering Stop mode. Software must wait until TC=1. The TC flag
remains cleared during all data transfers and it is set by hardware at the end of transmission
of the last frame.

This made me think if problem would be disabling TX (switching UART mode to RX only) regardless of taking into account TC (Transmit complete) flag.

I am preparing PR for review with change where TX disble is done in UART interrupt routine on TC interrupt.

[AlkaMotors]

@Vuk-SFL I propose we save some bytes and get rid of the interrupt entirely. Like so

[AlkaMotors]

I took a look on a scope and it quite nicely waits until the end of the packet and then the line becomes open drain again. There really is no reason for the interrupt here at all to disable dma channel as it can be done right before loading the buffer size again.

[AlkaMotors]

The other option is just to change pin mode to open drain and then never change direction. If you have enough pull-up on the line this is fine.

[Vuk-SFL]

Thanks for input and checking. I will try with open drain on pin approach and see how it behaves long term.