• State TI Thinks Resolved
  • Locked Locked
  • Replies 11 replies
  • Answers 3 answers
  • Subscribers 99 subscribers
  • Views 1847 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

RTOS/DRA72XEVM: Uart Interrupt Rx time-out

user5062300
Prodigy 130 points

Part Number: DRA72XEVM

Tool/software: TI-RTOS

Hi

when i use bspdrv_uart.c driver of m4 in DRA72x,i find that if i send datas to m4 in following conditions，the uart rx time-out always happen.

1、with data‘s’ length over 64bytes（now send ） 

2、in period 100ms

3、115200 baudrate ，

4、uartParams.rxThreshold  = 8;

5、interrupt mode 

my questions is that

1、why does the rx time-out hanppen?

     as  the interrupt is hw interrupt， its priority should high than the ti bios  thread task，so that if uart rx interrupt happen, bios tasks could not disturb it，

     so that the uart interrupt could be processed immediately, the rx time-out should not happen. unless uart rx interrupt is low than thread task。is that true？

2、how could i set priority of uart rx interrupt correctly？

    i find that ，the priority of uart rx interrupt is 0xff，which is the default value。when i set the priority to 0 or 1 or 2 with the functions" Void Hwi_setPriority(UInt intNum, UInt priority)"，

    the xdc hard fault happened， why？

3、how could i solve the  rx time-out  problem？

  • 0
    TI__Mastermind 19010 points
    Hi,
    1. Please see the time-out interrupt description at the bottom. Shortly, it guards against unreclaimed data in Rx FIFO after some time has passed.
    2. I'm not aware . Note that UART outputs one combined interrupt for all RX events.
    3. Rx time-out interrupt should not happen if there is no stale data in RX FIFO. E.g. if your Rx FIFO threshold was set to 8 bytes, then make sure that sender always transmits 8, 16, 24, 32, .... bytes. If your data has not fixed length, then you can setup your FIFO as 1-byte FIFO (disable FIFO). But even time-out interrupt happens, software should be able service it by simple read from the Rx UART_RHR register. This interrupt is not any different than normal Rx FIFO RHR interrupt.

    I hope this will be of some help.



    24.3.4.8.1.3.7.1 Time-Out Counter
    An RX idle condition is detected when the receiver line (uarti_rxd) is high for a time that equals 4x the
    programmed word length + 12 bits. uarti_rxd is sampled midway through each bit.
    For sleep mode, the counter is reset when there is activity on uarti_rxd.
    For the time-out interrupt, the counter counts only when there is data in the RX FIFO, and the count is
    reset when there is activity on uarti_rxd or when the UARTi.UART_RHR register is read.
  • 0 in reply to Stanislav Stilyanov
    Prodigy 130 points
    Hi Stilyanov，

    i have tried set the fifo disable， it rx time out get worse。
    then i set the fifo enble and use the RX_TRIG_GRANU1 = 1， and uartParams.rxThreshold = 1，the uart rx time-out happens as usual。

    is there any way solve it?
  • 0 in reply to user5062300
    TI__Guru 55685 points
    Hi,

    I have pinged a UART driver expert to help you on this.

    Regards,
    Rishabh
  • 0 in reply to user5062300
    TI__Expert 4935 points

    As per the UART IP, RX timeout interrupt is a mechanism for the software to flush out any data in the FIFO. This is true even if the FIFO is disabled i.e. threshold is set to 1. This interrupt happens if there is some data in the FIFO after the the timeout as mentioned in the spec. So this can happen is your ISR is delayed as well in a loaded system. Note this is not a error condition.

    What exactly are you trying to solve? It is not clear from the thread,

  • 0 in reply to Sivaraj R3681
    Prodigy 130 points
    Hi Sivaraj
    what i want do is that,

    1、fist，i use m4 in dra72x as a slave. outside the dra72x, there is ecu as one master.

    2、second, the master will send datas which length over 200 in period by uart in 115200 braud

    3、m4 uses the tibios gio_read in a thread to get what it recieved, and analyse them.

    after that use gio_write in same thread to send the analysed result.

    while, the uart always lost rx datas. i check the uartisr program and find that , the lost data things always follow with rx timeout 。

    so i think maybe the uartisr read is not processed in time，lead the datas lost and rx timeout。


    now i want to improve the priority of uart interrupt to solve this problem， but i failed。

    do you have any ideas about it？
  • 0 in reply to user5062300
    TI__Expert 4935 points

    Receiving 200 character from UART @ 115200 baudrate is already verified with the driver. So i don't think this is something to do with the interrupt priority.Kindly answer below.

    1. Is there anything else running in the system? Note that the UART driver uses BIOS SWI to handle the read/write operation. SWI has higher priority that tasks and lower that HWI.

    2. What is the read size you are providing for each GIO_read call? Did you try to provide 200 bytes and see if is working?

    3. The UART sample application reads 1000 bytes and sends the same back via UART TX. Did you try to test with this?

    We need to rule out UART driver configuration issues before going into interrupt priority.

  • 0 in reply to Sivaraj R3681
    Prodigy 130 points
    Hi Sivaraj
    1、i know the uart driver use the BIOS SWI to read and write. In the UART sample application" BSPdrv_uart.c", the uartIsr function posts swi to process the write and read。so to rule out the swi effect， i direct call the uartRxSwiHandler/uartTxSwiHandler function in uartIsr. the rx timeout also happened. Now i will confirm is there other function running which block the process。
    2、the read size what i set is 500，to avoid losing datas recieving。but cannot solve the problem
    3、the program i am using is the UART sample application in bsp_01_05_00_09。is it has the lose datas problem？
  • 0 in reply to user5062300
    TI__Expert 4935 points

    As I mentioned the driver is verified for this baudrate. So I doubt if this is some issue with the driver speed or interrupt priority. You need to see if the issue is somewhere else like board issue?

  • 0 in reply to Sivaraj R3681
    TI__Expert 4935 points
    One more suggestion is to do the GIO_read in a while loop till you receive all the data from the other end. If there is a gap in the UART line for more than the timeout period mentioned in the TRM, the RX timeout will happen and the driver will return with whatever it has received till that point. Then it is expected that the application call the GIO_read again with the remaining bytes and also manipulating the buffer address. Kindly try this
  • 0 in reply to Sivaraj R3681
    Prodigy 130 points

    Hi Sivaraj

    sorry for so late to reply you. i tried use the while loop to gio_read data recieved, it seemed the lost datas things get better, but it still occured sometimes.

    same time if i use the while loop in my task, it will add the cpu load to my program.

    do you have the idea how to improve the hwi interrupt priority?  will it solve the problem？ 

  • 0 in reply to user5062300
    TI__Expert 4935 points

    As i said changing the priority won't help. Kindly check with your local FAE for further support or debug.