This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

AM3358 hardware flow control latency

Other Parts Discussed in Thread: AM3358

Hi,

I am using a beagle bone black with an AM3358 processor and trying to communicate with a cortex-m3. I am using a debian distribution (official beagle package) with 3.8.13-bone70 kernel. The beagle UART1 serial port is being used. The hardware flow control is required because, the cortex M3 has no FIFO (one data register and one deserialisation register). Thus hardware flow control is required and it must react with 1 caracter delay at most.

For test purpose I am making some tests between a beagle (TX) and a Windows computer (RX). On the beagle I have configured the UART1 and the pinmuxing in order to enable the CTS/RTS function. I think the setup is correct because apparently characters are sent by the beagle only when the beagle CTS pin is low. But this only apparently works. Indeed when I take a close look with an oscilloscope I can see the CTS line going high but some caracters continues to be sent up to 1 ms after the CTS line is high !    As I am using a 115200 baudrate this means that up to 12 characters are sent after CTS is inactive (high state). 

According to the AM335x datasheet , Cf. 19.3.8.1.3.2 Hardware Flow Control :

Auto-CTS:

The transmitter circuitry checks uarti_cts before sending the next data byte. When uarti_cts is active,
the transmitter sends the next byte. To stop the transmitter from sending the next byte, uarti_cts must
be deasserted before the middle of the last stop-bit currently sent.

Thus in my understanding I would expect one maybe two caracters to be sent after CTS goes high level. Why so much latency ? Is this latency expected due to the usage of FIFO by the AM335x ? If yes is there a way to disable the FIFOs ? Any clue is welcome.

Thanks for your help,

Regards

  • Hi,

    This forum supports only the TI distributed Processor Linux SDK. All other Linux versions are supported by the community at beagleboard.org/.../Forums

    As for your question about the AM335X TRM description, this discusses the UART hardware. Latencies as you describe have not been observed with the Linux SDK. See this post for reference: e2e.ti.com/.../1178645
  • Hi,

    When I use the same scale a the solution you propose (100 ms/division), the screen capture bellow  illustrate the result.

    Blue : UART Rx , Pink CTS

    As you can see aparently the hardware flow control seems to work and no latencies are apparent.  But when I make a zoom with a scale of 200µs per division here is the result.

    As you can see for 520 µs some characters are being sent after CTS pin is deactivated. In these case 6 additional characters are being sent (but in some case the emission continues for up to 1 ms or 12 characters)

    Thus the question is can this behaviour be related to AM3358 UART flow control ? As there are FIFOs in the hardware device, when CTS is raised should the emission stop immediatelly or should the FIFO emission be emptied first ? 

    Thanks for your support,

    Regards

  • The auto-CTS function reduces interrupts to the host system. When auto-CTS flow control is enabled, the uarti_cts state changes do not have to trigger host interrupts because the device automatically controls its own transmitter. Without auto-CTS, the transmitter sends any data present in the transmit FIFO, and a receiver overrun error can result.

    Auto-CTS and auto-RTS can be enabled and disabled independently by programming the UARTi.UART_EFR[7:6] AUTO_CTS_EN and AUTO_RTS_EN bit fields, respectively.
  • Hi, 

    I have made some further test, and my problem was related to a software problem in the kernel.

    Kernel 3.8.13-bone70 : there is up to 1 ms latency in CTS signal handling (up to 12 characters)

    Kernel 4.1.13-ti-r34 : there is no latency, at most one character (as expected according to AM3358 datasheet)

    Thanks for your support,

    Regards