UART to RS485 with DFR0845 Board

Robotics & Edge Computing Jetson Systems Jetson Orin Nano
1

I’m trying to use the DFRobot DFR0845 board to send and receive RS485 signals on the Orin Nano Super Dev Kit. This board was chosen because it has hardware half-duplex to avoid timing issues on the GPIO pins for switching RE and DE on the Max485. I wired the board as shown in the diagram on the linked wiki and attempted a loopback test against a known-good Waveshare USB-to-RS485 adapter. The result was that I can read inputs from the USB adapter using the DFR0845 but cannot write outputs from the UART port back onto the RS485 bus. I tried numerous baud rates with no luck. When I send a message from USB→UART, I see the RX indicator on the DFR0845 light up and the content of the message decodes correctly. However, when I try send a message from UART→USB using the /dev/THS1 interface, the TX indicator does NOT light up and there is no signal transmitted on the RS485 A-B differential, as confirmed by an oscilloscope.

I have confirmed, using an oscilloscope and a manual UART loopback test, that the UART pins write the correct signal at the correct voltages, so I think this must be some issue with the board recognizing input signals from the Jetson, but I wanted to see if anyone else had any experience with this board or some suggestions on what to do next? The TX wire appears to be connected/undamaged in the oscilloscope tests. I’m using the 3.3V pin on the Jetson so the power supply matches the logic level.

More oscilloscope tests show that the Jetson TX pin appears to be current-limited in a way that leaves it unable to overcome a pullup on the DFR0845: it correctly pulls down to 0V when not connected to the DFR0845 but it only pulls down to 2V when connected. I attempted a software fix for this with busybox. Per the Orin Technical Reference Manual:

PADCTL_G3_CFG2TMC_UART1_TX_0
Offset: 0xac
Read/Write: R/W
Parity Protection: Y
Shadow: N
SCR Protection: PADCTL_G3_SCR_SCR_UART1_TX_0
Reset: 0x00000000 (0bxxxx,xxx0,0000,xxx0,0000,xxxx,xxxx,xxxx)
Bit Reset Description
24:20 0x0 CFG_CAL_DRVUP
16:12 0x0 CFG_CAL_DRVDN

So I did:

sudo busybox devmem 0x024300ac w 0x0001F000

To set the DRVDN register to its maximum strength (the register started at its default value of 0x0). However, it appears that this had absolutely no effect; pin 8 still only pulls down to 2V. I assume the only good fix here is to try a logic buffer, but I’m not terribly confident I chose the right register or value based on these results and would appreciate any input from those with more experience!

4

Hi sam283,

What’s the Jetpack version in use?

How do you connect DFR0845 and the Jetson?
(i.e. which UART interface you are using from Jetson? Which GPIO(of Jetson) you used to connect with RE/DE pin(of DFR845)?)

Do you mean the UART loopback test working well and the current issue is specific to RS485 transaction?

6

Hi KevinFFF - I’m using JetPack 6.2.1. I’m using UART1, so pins 8 (TX) and 10 (RX).

The DFR0845 doesn’t have RE and DE pins, it does hardware muxing to see whether I’m trying to transmit and otherwise keeps the RS485 interface in receive mode. So the only connections to the Jetson are 3.3V power, GND, TX on pin 8, RX on pin 10.

Yes, the UART loopback test worked well and I additionally verified with the oscilloscope that the waveform looked as expected, so I think the issue is that I can’t pull down on pin 8 hard enough to trigger the hardware muxing on the DFR0845 due to current limits on the Jetson GPIO pins. I’ve ordered some logic buffers and will update on here with results from those!

8

That is the right register to use but UART1_TX is a boot strap, so the module has a buffer on the signal to prevent the carrier board from interfering with the voltage level when the strap is sampled during boot. From the Jetson Orin NX Series and Orin Nano Series Design Guide:

image
image1069×593 74.7 KB

The change to increase CFG_CAL_DRVDN is correct but did not affect the actual signal on the carrier side because of the buffer. The buffer’s max output low current (IOL) is <8mA so it isn’t very strong. Adding an output buffer on the carrier for UART1_TXD that can more strongly drive low is the right move.

9

Hi @KevinFFF and @ChrisB_NV - I had less time than expected to work on this but I do have some updates to share:

Debugging Steps

  1. Confirmed the TX signal is clean when unloaded. As I previously mentioned, with nothing connected to Pin 8 (UART1_TX), the oscilloscope shows a clean 3.3V-to-0V square wave at the expected baud rate.
  2. Connected a BSS138 bidirectional level shifter (both sides at 3.3V, acting as a buffer). The output only pulled down to ~1.5V. Moved HV reference to 5V (the DFR0845 accepts both 3.3V and 5V logic). Output only pulled down to ~2V. The BSS138 does still sink some current with its MOSFET, so I tried another level shifter too.
  3. Tried a TXS0108E level shifter (push-pull topology, completely different from BSS138). Same problem — output only reached ~2.4V low.
  4. Measured the Jetson TX pin voltage with the shifter connected. The pin itself sits at ~2V when driven low — it’s not a shifter problem, the Jetson can’t pull the line down.
  5. Applied a device tree overlay to explicitly set the pin as push-pull, non-tristate, open-drain disabled:
   hdr40-pin8 {
       nvidia,pins = "uart1_tx_pr2";
       nvidia,function = "uarta";
       nvidia,tristate = <0x0>;
       nvidia,enable-input = <0x0>;
       nvidia,open-drain = <0x0>;
   };

No change in behavior.

  1. Tested with static GPIO output (not UART) on Pin 8 with the shifter connected. Same result — pin sits at ~1.8V when driven low. Measured ~0.4mA of current. This confirms it’s not a UART peripheral issue.
  2. Tested a completely different pin (Pin 16) as GPIO with the same load. Same behavior — ~0.5mA, can’t pull low.

It seems very odd to me that I only get 0.4mA (vs 4-8mA expected) and I’m trying to figure out if this is some configuration problem or if this specific Jetson is having problems. Any suggestions would be appreciated, and I’ll try another Orin Nano when I have the chance.

10

Do you mean pins 8 and 16 of the J12 expansion header on the Dev Kit Carrier Board? Those are both behind the same 1.8V to 3.3V level shifter on the carrier (U14 in the schematics in Jetson Orin Nano Developer Kit Carrier Board Reference Design Files).

So there are two devices in the UART1_TXD path from the SoC to the J12 header on the Dev Kit: the buffer in the figure in my previous comment that protects the signal during boot as a boot strap on the module itself and then a 1.8V to 3.3V level shifter on the carrier side.

11

Hey Chris and Kevin, thanks for your help with this. I eventually solved my problem using a third level shifter, the SN74AHCT125N. This one is a CMOS-based design that draws approximately zero current through the Jetson pins. It also has the ancillary benefit of cleaning up the signal at high baud rates; I now get a beautiful square wave out of the shifter even at 1 Mbaud. This sinks enough current to work with the DFRobot board with no load on the UART pin. Thanks again for working through it with me, your troubleshooting helped me become confident enough to order and test another shifter.