Cube Orange UART Inversion & Half Duplex Problems

ArduCopter Copter 4.0
1

I’m under the impression that the half-duplex and inverting support of the H7 in the Cube Orange should allow for a straight connection to FrSky SPort on a receiver (in this case an R-XSR). However, I’ve been having some issues.

Without half-duplex set in SERIALx_OPTIONS, the line behaves correctly; when the receiver releases the line, it stays at 0V. However, with the half-duplex bit set, when the line is released it gets pulled to 3.3V. When connected to the receiver, this means the line ends up at around 2.25V, likely due to a pull down in the receiver.

If I add an external resistor to ground, the telemetry is able to work, but the signal doesn’t look great; only reaching 2V when the FCU has the line. Conversely, when the S-XSR has the line, the signal looks fine.When the line is released by both ends, the voltage (with my external additional pull down) is approximately 0.4V.

This is through the mini carrier board, which, as far as I can tell, just has straight through connections from TELEM2 to a TSX0108 level level shifter inside the cube. This is tied to 3.3V both sides and seems to just be there to protect the FMU chip. I’m unsure if the state of the FMU ouput causes the level shifter to drive the line, though it seems likely given the behaviour is as expected without the half-duplex mode.

The ST reference manual is rather brief on the expected pin setup for the half-duplex mode just saying:

…the I/O must be configured so that TX is configured as alternate function open-drain with an external pull-up. (p2227, Sec 51.5.15)

This is seen on master. I have tried a few variations on pull down settings in libraries/AP_HAL_ChibiOS/UARTDriver.cpp:1385 but none seemed to make any difference.

Does anyone have any insight on the internals of the UART drivers that might explain things?

2

In chibios_hwdef.py, the output type of a pin defaults to PUSHPULL if not otherwise stated. For the half-duplex mode, the TX line should be set to open-drain as per the reference manual. I’m unsure if that will result in a failure to properly set the high signal when the TX portion has control of the pin. At the moment the HDSEL register is cleared and set with each transmission cycle so similar code could be used to set the output type.

The TX line should likely be set to something similar to below. However, the alternate function number depends on the hardware.

ioline_t iomode =
        PAL_STM32_MODE_ALTERNATE
        | PAL_STM32_OTYPE_OPENDRAIN
        | PAL_STM32_OSPEED_MEDIUM
        | PAL_STM32_ALTERNATE(n) /* Depends on hwdef */
        | PAL_STM32_ASCR_OFF
        | PAL_STM32_LOCKR_OFF;

The alternate function number could be obtained by retrieving the current alternate function number using readLineMode() then using palSetPadMode() or similar to set the pin output type. A similar approach is taken to change push/pull setup in stm32_util.h.

Useful file paths for reference

Defaulting to PUSHPULL:
libraries/AP_HAL_ChibiOS/hwdef/scripts/chibios_hwdef.py:301

Push pull setup changes:
libraries/AP_HAL_ChibiOS/hwdef/common/stm32_util.h:90

STM32 IO mode flags:
modules/ChibiOS/os/hal/ports/STM32/LLD/GPIOv[123]/hal_pal_lld.h:53

3

Setting the mode to open drain appeared to have no effect on the behaviour, though I’m not 100% convinced I set the right pin. I still think the open drain mode should be set for RX to conform to the reference manual. However, it is likely that board implementations don’t include the necessary pull resistors and wouldn’t be able to if a user wanted to invert the port.

4

Hi Rob,

Did you find a fix for this? I’m having the same issues with my cube orange and my R-XSR, and can’t get SPort or FPort telemetry to work.

I’m measuring around 2.2V on the SPort line, but only have a Digital Multimeter to hand at the mo. Have a logic analyser on the way and will try to get an oscilloscope from work to test it with.

But it looks like a pull up resistor is required on the TX line?

Cheers

5

pull down of approx. 10K, An Open Source Frsky Telemetry Script for the Horus X10,X12 and Taranis X9D,X9E and QX7 radios

1 Like
6

I’m using an external 1N4001 diode to do the duplexing. With just inverting set in serial_options.

Same issue is present on the CUAV Nora (also a H7).

1 Like
7

For CUAV V5 Nano I used a 2k pulldown and SERIALx_OPTIONS,7

1 Like
8

Adding a pulldown was as far as I got. Unlike others I failed to note the value I used. Summary here. I imagine it was similar to @iampete’s value as that works…

Looking at the datasheet for the TXS0108E, the chip’s pullup is 4k when driving high. TI also have an application report for external pull resistors with TXS devices: Effects of External Pullup and Pulldown Resistors
on TXS and TXB Devices

TI recommend 50kOhms or greater, though I’m not sure if that will actually work in situ.

1 Like
9

Amazing, thanks everyone. A 10k pull down resistor worked great.

On the oscilloscope the line was floating at 2.2v before, and was then down at ~0.3v after, and telemetry on SPort and FPort works great now!

1 Like
10

Looks like a similar thing popping up elsewhere…

11

Update from 12.07.2021.

For Cube Orange, just make 10K resistor mode between Signal and GND on S.Port.

Worked fine for me on Telem2 (Serial2) port