Serial line seems to occassionally drop a character

[TomM]

Hi Mark,

I've got two MCF52258's on the same PCB using a direct cross linked TXD2/RXD2 to perform SIPC (Serial Inter-Processor Communication).  I've implemented message packets that include packet length info and checksums so I can try to make sure I don't process junk.  My problem is that I'm occasionally seeing checksum errors in the received data from one processor, i.e. the one that doing most of the transmitting.  At this point, the retry logic in the code detects the UNACKED message and resends the exact same data using the same code to transmit it again. This last point combined with the fact that I've included verification that fnWrite() did queue the entire message makes me fairly confident my code is sending what it thinks it is. 

So the real issue is that when I use a logic analyzer set to trigger on the checksum error (software activated testpoint), the serial message on the wire is one byte short of what it should be, i.e. 87 instead of 88.  It required the 1st byte of the retry message to complete the packet processing and decide the checksum was incorrect, however the retry message is 88 bytes as expected.

So I'm wondering if you recall any issues with the serial driver losing one character in a transmission block?  I searched the Forums and didn't see any likely entries.

FYI:
The baud rate being used is 750kb and I've attached a file containing the serial port initialization.

Thanks Tom

[mark]

Hi Tom

I don't know of any issue with lost tx characters.
I see you are not using DMA for transmission, which is however not a problem since in interrupt mode there is no risk of losing tx bytes since, even if the interrupt had problems keeping with with the 750k Baud rate it would just add a little inter-character space between characters sent.

I see you are using HW flow control - is it possible that the CTS line gets negated for a short time and something goes wrong when restarting? That is, do you see any CTS movement at the same time as a character loss, which could point to something in this area?

After you have see a missing Tx character I would take a look in the TTY output buffer (after stopping the operation asap). You should find the last message there and you can check for two things:
1- Is it complete? If not it may be that there was a problem when the tx data was put to the buffer rather than when sending it out over the UART.
2. If you see something missing is it at the end/start of the circular buffer? If so it may point to an issue with handling the circular buffer in the UART driver. Although I am not aware of any known issues things like interrupts writing to the same buffer at the same time are potential race-states if something were not be be correctly protected (circular buffer wrap being potentially more sensitive to such).

Regards

Mark