Reading UART Tx FIFO level

[lpcware]

Content originally posted in LPCWare by graynomad on Sun Dec 09 03:52:58 MST 2012
I'm writing a driver for a UART (on the 1227), so far it's working well but if I send too many bytes the FIFO fills and I lose characters. No problem I just write a buffer function that creates a software FIFO for the overflow.

So to implement that I need to test the hardware FIFO level, if it's full write to the software buffer, if not write directly to the hardware. But no matter what I do I get a value of 0 for LPC_UART0->FIFOLVL.

Here's the test code I'm currently using.

void serialWrite (uint8 b) {
    uint8 x = (LPC_UART0->FIFOLVL >> 8) & 0x0F;
    if (x < 15) {
        LPC_UART0->THR = 0x11;
        LPC_UART0->THR = 0x22;
        LPC_UART0->THR = 0x33;
        LPC_UART0->THR = LPC_UART0->FIFOLVL >> 8;
        LPC_UART0->THR = 0x44;
    } else {
        fifoWrite (s->TxBuffer, b);
    }
}

Because I think stopping the processor to use the debugger will allow the FIFO to empty and give me a bogus reading of FIFOLVL for testing I write three bytes into the FIFO then write the TXFIFOLVL bits from the register and finally another byte just to frame the level data.

I always get 0 for the LPC_UART0->FIFOLVL >> 8 byte when presumably it should be 4. Here's a trace of the transmission

[IMG]http://www.robgray.com/temp/serial-fifo-trace.png[/IMG]

This should be simple right? Am I missing a secret handshake or something?

[lpcware]

Content originally posted in LPCWare by graynomad on Mon Dec 10 09:23:28 MST 2012
A quick Google didn't come up with much, the stuff cfb pointed to plus it brought me back to one of our threads

http://knowledgebase.nxp.com/showthread.php?t=2231

Where Zero says

---

Quote:
Unfortunately reading FIFO status via FIFOLVL doesn't work.

---

So I guess that's it then. This is a real gotcha, you'd think there would be a larger Google footprint for it, especially as I assume these peripherals are common to a lot of LPCs, or is that not the case?

The good news is that if you keep your own counter the end result is the same, just another instruction or two.

[lpcware]

Content originally posted in LPCWare by graynomad on Mon Dec 10 09:06:30 MST 2012
Thanks for the links cfb

---

Quote:
On the NXP forum there is one related to the LPC1226:

---

I'd say this bloke has exactly the same problem, unfortunately no resolution.

I like the idea of writing to an array and may give that a go, but my version that writes out the port should work as well I think. As I mentioned above I'm not using the debugger for this because it can't be trusted here.

---

Quote:
incorrect definition of FIFOLVL in the header file for the LPC1768:

---

I also thought this might be the problem, I've checked and rechecked LPC122x.h and I think the definitions are right. I also tried directly reading the address 0x40008058, still 0.

---

Quote:
I assume you are enabling the FIFO in FCR?

---

Yep. I know the FIFO is working because I've written a burst of 20 bytes directly into the THR and I only lose the last few bytes. I've also written a version of that serialWrite() function that maintains it's own counter, that works perfectly and displays all the symptoms you would expect with a working FIFO.

---

Quote:
what does your uart init code look like?

---

All manner of pointers to this and that, probably would only muddy the waters posting it all here but this is the FCR bit

uart->FCR = (1 << 0) |        // Enable both FIFOs
                (1 << 1) |        // Reset Rx FIFO
                (1 << 2) |        // Reset Tx FIFO
                (2 << 6);        // RX FIFO trigger level = 8 chars

Where "uart" is a pointer to the UART base address. This all works, verified in the debugger and also with the logic analiser.

I can't believe this is a bug in the silicon, I'm still open to it being  a bug in the documentation, and of course the most likely candidate is  my code but I've been at this every way from Sunday and I just can't get  it to work.

I'd raise it with NXP but they never bothered to answer my question so that's not worth the effort.

[lpcware]

Content originally posted in LPCWare by Skashkash on Mon Dec 10 06:16:39 MST 2012
The M0 chips I've been working with don't even have a FIFOLVL register so I can't test anything.

   But, what does your uart init code look like? I assume you are enabling the FIFO in FCR?


I have had a little trouble dealing with the FIFO on some of the other chips. You can only tell if the FIFO is completely full or empty.

You may want to try writing 16 (or more chars) to the uart, and then try reading FIFOLVL. May also help to do these tests at very low baud rates to insure that the chars are not clocking out while you are reading the registers.

[lpcware]

Content originally posted in LPCWare by cfb on Mon Dec 10 06:06:04 MST 2012
If you search this forum for 'FIFOLVL' you will find similar problems mentioned several times. However, I couldn't see any that specifically referred to the LPC1227.

On the NXP forum there is one related to the LPC1226:

http://forums.nxp.com/viewtopic.php?t=5636

On the mbed forum there is a report of an incorrect definition of FIFOLVL in the header file for the LPC1768:

http://mbed.org/forum/bugs-suggestions/topic/705/?page=1#comment-3501

HTH,
Chris.

[lpcware]

Content originally posted in LPCWare by graynomad on Sun Dec 09 17:26:00 MST 2012
No ideas? This is a real show stopper for me.