iMX95 Aquila Development Board RS485 issue

Hi,

Over the last day I have been trying to get the RS485 peripheral on the Aquila Development Board working on the Aquila iMX95. I have come across several issues that I cannot figure out and was wondering you could help me with.

I have validated that the iMX95 sends out the right data to the RS485 driver. However, what came to my attention was that the RTS pin was not being driven. The RTS pin was continuously pulled high. I found this page and this note that both show how to configure the kernel or user-level to accept and work with RS485 and pull the RTS pin down when necessary. Upon first validation this partly worked.

I measured:

  • 1V8 on the UART_2_RTS_JMP (see image) net when the iMX95 did not try to send messages and 1V16 on the same net when the iMX95 tried to send messages. This is weird, because it is expected to be pulled high or low, not in between. The Aquila iMX95 should be able to drive the 10k resistor to ground easily.

After that I disconnected the Aquila iMX95 from the jumper and applied 1V8 or GND to the jumper itself. This time the UART_2_RTS_JMP net became 1V8 and GND respectively. So, the net can be driven high or low.

Then, I measured on the other side of the inverter on J18 at pad 1 while applying 1V8 and GND to the UART_2_RTS_JMP. In both cases I measured 0V. After this I applied 1V8 directly to J18 and that solved made the transceiver work when sending.

My suspicion is the following:

  • U45, an inverter with schmidt trigger inputs is broken.

The next thing would be to ask:

  • How can I confirm my hypothesis?
  • And also, is U45 necessary? Why is R407 around (and can I place that one instead)? Should it not be easier to not invert the signal, since this does eliminate the rs485-rts-active-low setting.

Hi, I’m the Toradex AI Assistant.

I might make mistakes or occasionally get you wrong. Our support team will step in if needed.


Based on the Aquila Development Board V1.2A schematics (1), the RS485 implementation uses an inverter (U45, 74LVC1G14SE-7) between the UART_2_RTS signal and the RS485 transceiver’s DE (Driver Enable) pin. Let me address your questions:

Confirming Your Hypothesis

Your measurements strongly suggest U45 may indeed be faulty. To confirm:

  1. Check U45 power supply: Verify that U45 pin 5 (VCC) has 1.8V and pin 2 (GND) is at ground potential.

  2. Input/Output verification: With the iMX95 disconnected from the jumper:

    • Apply 1.8V to U45 input (pin 1) → output (pin 4) should read ~0V
    • Apply 0V to U45 input (pin 1) → output (pin 4) should read ~1.8V

    If both outputs read 0V regardless of input, U45 is likely defective.

  3. Check for shorts: Verify there’s no short between U45 output and ground that could be pulling the signal low.

Why the Inverter Exists

According to the Verdin Carrier Board Design Guide (2):

“The schematic shown below inverts the RTS signal for the data enable input of the transceiver. Some modules allow inverting the signal in the software. However, it is recommended to keep the inverter circuit in the RTS signal to maintain compatibility with different modules and drivers provided by Toradex.”

The inverter ensures that when RTS is asserted (low), the RS485 driver is enabled. This maintains consistency across different Toradex modules and software configurations.

About R407 (DNP - Do Not Populate)

R407 is marked DNP (Do Not Populate) in the schematic (1). This resistor would bypass the inverter if populated, but it’s specifically left unpopulated to maintain the inverted logic path through U45. You should not populate R407 as a workaround.

Recommended Actions

  1. Short-term workaround: If U45 is confirmed faulty, you could temporarily bypass it by:

    • Removing U45
    • Connecting UART_2_RTS_JMP directly to J18 pad 1
    • Modifying your device tree to remove rs485-rts-active-low property
  2. Proper solution: Replace U45 with a new 74LVC1G14SE-7 or compatible Schmidt trigger inverter.

Software Configuration

For proper RS485 operation with the inverter in place, your device tree should include (2):

linux,rs485-enabled-at-boot-time;
rs485-rts-active-low;

The intermediate voltage you measured (1.16V instead of proper high/low) when the iMX95 was connected strongly suggests either:

  • U45 is partially damaged
  • There’s a loading issue on the RTS line
  • The iMX95 GPIO isn’t properly configured as RTS function

Could you confirm which OS version you’re running? This will help verify the correct device tree configuration for your setup.

Best regards,
Toradex AI Assistant.


Did you like my answer? :+1: :-1:

If I answered your question, please tick the “Solution” checkbox.

For follow-up questions to me, please use @ToradexAI in your post.

Sure, you can try to populate R407 or use a jumper wire to connect J18(1) to J8B(7) and connect together J18(1 anfd2) to pull RTS signal it low. Then replace the respective rs485-rts-active-low to rs485-rts-active-high at your Device tree. Double check if the UART_2_RTS signal behave as expected when you transmit data on that UART.

Will do so! Thanks for the advice.
Daan

I also found this Errata, which states that this is an V1.2 issue. Errata #4: HAR-11139 – The RS485 interface is not functional.

Will keep this in mind and create a workaround.

The solution that works for me has been:

  • Removing the inverted Schmidt trigger
  • Jumping resistor R407
  • Changing the device tree from rs485-rts-active-low to rs485-rts-active-high

I suspect that this will be fixed in Aquila Development Board V1.3, we currently use V1.2C.

Yes it fixed in the Aquila Development Board V1.3: