UART Read FIFO problems (C6678)

Alberto Chessa,

It confuses me, since application and program are often used to mean the same thing, which is the code that is running on the C6678.

Can you enable just the TX FIFO, since that data is continuous? This appears to be a case where you would not want to use an RX FIFO because the external source does not send continuous data, but just occasional single chars.

It is interesting that once you send a lot of 'q' chars, then you are able to read it correctly. Perhaps in this case the FIFO has filled. Try typing individually the 'q' key and see how many much be sent before you get good data.

When you get bad data, is there a return code that says there is no data present yet?

Sorry, but this is the best I can do. You have waited a couple of days, and I at least wanted to get something started with you.

Please let us know what experiments you try and what you find.

Regards,
RandyP

Yes, I'm sorry: application and program is the same things.

Anyway maybe the problem regards also the data ready flags from the UART. For instance, the following program that only use the platform library for EVM6678, doesn't break when I hit "x". If I set the second breakpoint, I can see that the platform_uart_read() don't see the Data Ready. So, I try to recompile the uart driver to cache the LSR so to "remember" the DR status bit read during the write operation also (the cached flag is cleared after a read operation): the program detect all the keystroke, but the char extracted form the uart is wrong. Finally, if I disable the fifo everything seems to work.

#include "platform.h"

uint8_t *Osal_platformMalloc (uint32_t num_bytes, uint32_t alignment) { return 0;}
void Osal_platformFree (uint8_t *dataPtr, uint32_t num_bytes) { }
void Osal_platformSpiCsEnter(void) {  return; }
void Osal_platformSpiCsExit (void) { return; }

volatile unsigned long x_hit, skip_chars;

unsigned char datum;

void main(void)
{

    platform_uart_init();
    platform_uart_set_baudrate(115200);

    for(;;)
    {
        platform_uart_write('.');
        Platform_STATUS sts=platform_uart_read(&datum, 1);
        if (sts==Platform_EOK) 
        {
          if (datum=='x')   /*then, BREAKPOINT 2 HERE*/
          {
              ++x_hit;                          /* BREAKPOINT 1 HERE !!!! */
              skip_chars=0;
          }
          else
            ++skip_chars;
        }
    }
}

Alberto Chessa,

This is not how the FIFO mode is intended to be used. You are doing single char transfers both ways and polling for each char, which is the classic non-FIFO method.

My suggestion is that if you want to get FIFO mode working, convert your program to use interrupts and get it working that way, which would be more efficient.

If you are trying to evaluate this feature of the UART to the bit level, you may need to modify some of the functions that are used from the platform and uart source files. That is not an official statement about the drivers, but it would make sense to me that the drivers are intended for char mode and not FIFO mode. What differences there would need to be, I do not know. For using the FIFO in your real application, you would not want to use the code the way your test program does.

My apologies if this is not of any help.

Regards,
RandyP

RandyP,

Regardless the best way to use the FIFO in my scenario, I wonder why the C6678 UART doesn't work as expected (I'm reusing some code that  work without problems on other UART with FIFO). IMHO it should be considered a bug, since the documentation say nothing about such a limitation.

I agree with you about the interrupts consideration, but unfortunately I have to use it for a non intrusive monitoring of my real-time application: the monitor runs in the lower priority thread and it should never introduce real-time interrupts latency generated by the I/O to the UART.

With the performance of the C6678 I could migrate to an interrupt FIFO driver, but so far I prefer to disable the FIFO and continue to work in polling. For bulk data transfer, I'll use an interrupt approach (on my final system the Ethernet is not accessible and I have to use the UART to download the code).

Thanks,

Alberto

In my real sw I'm not using the original driver delivered with the PDK: I took it as a base only and then I rewrite it with wating loops that should not introduce latency in the interrupts. I thought I introduce a sort of bug modifing the original code, so first I look at the UART manual, then I verify for tx/rx erros (no erros at all signaled by the UART), at last I build a simple test program using the PDK libraries to see if the problem is in the UART or in my code (the behaviour is exactly the same).

Thanks, I'll look to EDMA3 also and I'll post if I'll produce something of usable.