Serial driver - abandon FIFO data on error?

My understanding is that the better HW FIFO UART designs have a 'wider fifo' that includes the error flags, for each byte. The errata I have seen as well, indicates they do not always get the tracking of those flags quite right!

So, I would say 'best practise' would be to implement a similar SW scheme: slightly more work, but it gives much more info for fault anaylsis, and as you indicate, works better by discarding less data. An easily variable FIFO size, and trigger points, can also help testing/tuning. Skewing the clocks outside spec, can be one way to guarantee errors, and tert your error recovery.

-jg

I'm not writing a software UART, just a software buffer extension of a hardware UART with 16-byte FIFO. When an overrun error occurs, know that it occured after the 16 bytes in the FIFO. Any other error (FE, PE) I have no idea to which character it pertains since it is possible that I don't get into the interrupt routine until several chars have been queued. That is because the RX ISR will need to be preemptable by other much more time critical interrupts in a real-time controller.

Yes.

Thanks for input.

I think that you should either design your system such that an over- run error is impossible except as a result of a hardware failure (insure you will always service the interrupt in time to drain the hardware fifo even with the pipe kept full at maximum baud rate), or else you should use an acknowledgment protocol and just throw away data when an overrun error occurs.

For the former, I'd connect the overrun error flag to some kind of attention-grabbing message and then hammer the system with trivial data, interspersed with the most time-consuming commands/messages you have.

That's of course only testing what valid data over a functioning signaling scheme can do. Data framing and timing errors are a whole other problem.

Assume the buffer is full when it's 16 bytes from actually being full. On overflow, read the 16 bytes from the FIFO into the buffer and report to the user there was an overflow condition and document that all of the data in the buffer is valid up to the point of overflow.

Bill

So, this device has a HW CHAR fifo, but not an HW Flag/error fifo ?

- seems to have not caught up with the better uart designs... ?

-jg

So it would seem.

That won't be a problem for the system design, which will be guaranteed to not overrun. But the driver should deal sensibly with trouble nonetheless.

Thanks for input.

That's worth looking into. Thanks for the input!

It took me a while to figure out the functionality of two bits in a register (the documentation can be a bit vacuous).

Indeed, the F2812 tracks framing and parity errors for each char in the FIFO.

There are two bits: SCIRXBUF.SCIFFFE and SCIFFPE which reflect the status of the character at the top of the FIFO (the one you are about to read from SCIRXBUF.RXDT).

There are also a set of error bits for FE, PE, etc., which just latch whenever an error is detected. I had thought the SCIFFFE and SCIFFPE were redundant with these (and wondered why) until I figured out that these two track the error status of the top FIFO char.

It took me a while to figure out the functionality of two bits in a register (the documentation can be a bit vacuous).

Indeed, the F2812 tracks framing and parity errors for each char in the FIFO.

There are two bits: SCIRXBUF.SCIFFFE and SCIFFPE which reflect the status of the character at the top of the FIFO (the one you are about to read from SCIRXBUF.RXDT).

There are also a set of error bits for FE, PE, etc., which just latch whenever an error is detected. I had thought the SCIFFFE and SCIFFPE were redundant with these (and wondered why) until I figured out that these two track the error status of the top FIFO char.