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.

UART FIFO not being used, when it should

Hello,

I'm working with starterware 02.00.00.07 and Beaglebone. I cannot get the FIFO of the UART0 to work. I would like to send a few kb of text via UART0, 64 bytes at a time in the UART0_Isr. Check this out. In the interrupt in call "UARTCharPut" 64 times. The duration of that interrupt is 5.6ms (measured with a DMTIMER), which means that UARTCharPut waits for each character to be transmitted. If I use the UARTCharPutNonBlocking, only two characters get transmitted and the rest get lost. 

My FIFO setting is standard:

config = UART_FIFO_CONFIG(UART_TRIG_LVL_GRANULARITY_1 , UART_TRIG_LVL_GRANULARITY_1 , 1 , 1 , 1 , 1 , UART_DMA_EN_PATH_SCR , UART_DMA_MODE_0_ENABLE);

UARTFIFOConfig(SOC_UART_0_REGS , config);

And the ISR is nothing special aswell, copied from the UART echo example:

case UART_INTID_TX_THRES_REACH:

   for (a = 0; a < 64; a++) UARTCharPut(SOC_UART_0_REGS,'A');
   UARTIntDisable(SOC_UART_0_REGS, UART_INT_THR);

   break;

To sum up, that for loop takes 5.6ms, meaning the UARTCharPut puts only one char a a time and waits for it to be transmitted, as if the FIFO was not present. I a previous post on this form, I saw an example of sending 64 chars using the UARTPuts, but UARTPuts uses the UARTCharPut, so It shouldn't make any difference. Anyways, if I send a few kilobytes of text in this way, the processor would be in the ISR all the time. Not good.

Appreciate any help!

Thanks!

  • you can track the UARTCharPut, you will found this function have not use the fifo.it send one char until FIFO is empty and shift register is empty. actually, you can use UARTCharPut in the main program , not in the  isr.

    I also got puzzled on uart fifo. i've found that whether the triggle value is set, it interrupts once a char reaches,even fifo triggle value is bigger than one.

  • Thanks for your input. If the UARTCharPut shouldn't be used in the ISR, which function should then be used to write to the transmit fifo ?

    Best regards to all!

  • in the nornal operation, in the isr ,you can use the following(pseudo code):

    while(tx_FIFO is not full && string is not send over)

    {

         THR = char;

    }

  • Hello Jure Tomazic/Aking Jin,

    Apologize for the delay in responding to your queries.

    The issue that you have raised about Transmitter FIFO not being used in UART Interrupt application is valid. Using the API UARTCharPut() in the UART ISR as well as in the utility function UARTPuts() would result in non-utilization of the 64 byte FIFO. Thus the performance of the ISR and UARTPuts() takes a hit.

    An Incident Report (IR) has been raised and the process of fixing it is underway. The fix will be reflected in the next release of StarterWare.

    However you can use a temporary solution proposed below.

    #define NUM_BYTES_PER_INTR         (50)

    static void UARTIsr(void)

    {

         ------------------------------

         ------------------------------

         static unsigned int count = 0;

        switch(intId)

        {

            case UART_INTID_TX_THRES_REACH:

                for(lpIndex = 0; lpIndex < NUM_BYTES_PER_INTR; lpIndex++)

                {

                    HWREG(SOC_UART_0_REGS + UART_THR) = str150[count];      /* ‘str150’ is a 150-byte string. */

                    count++;

                }

               

                if(count == (sizeof(str150) - 1))

                {

                    UARTIntDisable(SOC_UART_0_REGS, UART_INT_THR);

                }

            break;    

            --------------------------------------------------------------------------------

            --------------------------------------------------------------------------------

            --------------------------------------------------------------------------------

        }

    }

    Aking Jin said:

    I also got puzzled on uart fifo. i've found that whether the triggle value is set, it interrupts once a char reaches,even fifo triggle value is bigger than one.

    This comment by Aking has been accepted. This observation was made at the developer’s end also.

    Later it was found that writes to two registers namely Trigger Level Register (TLR) and FIFO Control Register (FCR) was not taking the necessary effect because the pre-conditions that were required to be satisfied before their access was not taken care of in the UART driver file. These issues have been recorded in the form of IRs and fixes have been provided. These fixes will be available as a part of the next release.

    However to help you continue your work with trigger levels, the suggestion would be to set the ENHANCEDEN bit of Enhanced Feature Register (EFR) [bit 4 of EFR] to 1 before an access of the TLR or FCR. Specifically, TLR has been accessed in the API UARTFIFOConfig() and FCR has been accessed in the API UARTFIFORegisterWrite().

    I hope I have made myself clear. Please revert with your comments, if any.

    Thanks and Regards.

    Gurudutt.

  • Gurudutt Bharadwaj,

    yes, I have tested it . that's right.

    Tks.

  • Hello,

    Sorry It took me so long to get back to the problem. Anyways, I cannot seem to set the 4-th bit in the EFR. If I do the standard :

    HWREG(SOC_UART_0_REGS + UART_ERF) |= (1<<4);

    The value of EFR (location 0x44E09008) changes from 0X01 to 0XC1, which is odd to say the least. Could you please show me exactly what you guys did to solve the problem?

    Thanks and best regards,

    Jure

  • Hello Jure,

    The Enhanced Feature Register (EFR) can only be accessed in Register Configuration Mode B, that is, when the Line Control Register (LCR) holds a value LCR[7:0] = 0xBF. Therefore make sure that LCR[7:0] has the value 0xBF before writing to the EFR. You can refer to the API UARTEnhanFuncEnable() present in ‘drivers/uart_irda_cir.c’ in StarterWare 02.00.00.07 release package which writes to the EFR register.

     

    Thanks and Regards.

    Gurudutt.

  • Hello Gurudutt,

    In your post above, you mention this UARTFIFOConfig() problem will possibly be fixed in the next release of Starterware.  Have you heard a time frame of when the next Starterware release for AM335x processors may happen?

    Thank you,

  • Hi,

     The next release on StarterWare will be roughly around end of June. Just to make sure and set the expectation right can you re-iterate the problem for which you are expecting the fix.

    So that we can confirm if the issue is getting fixed in the next release.

    regards

    Baskaran