Missing char's in Serial Interrupt UART driver

[Cdn_aye]

Hi

I have read through the posts on this for the blocking and non blocking modes of the serial driver and it seems to me that some of the char's are being translated. I tried clearing the flags as in the code inserted but it doesn't do any good. You can see from the logic analyzer that we are receiving a specific stream, but from the snapshot of the debugger variable buffer we are missing some char's. We don't always get the same char missing, sometimes it is the '\r', other times it is the '\n', we are consistently missing the "O" in OK. The code implements a timeout check and number of char's expected check, these work correctly. We also check the status on the ioctl settings with the debugger and this yields success. Is there an error in expecting no translation of the char's in blocking mode, when we clear the IO_SERIAL_TRANSLATION flag?

Any advice would be appreciated. Thanks.

Robert

[VinGanZ]

HI,

We are exactly at the same situation where we are losing a \r or \n from an external stream on the UART5 receive buffer.

We are using MQX4.0.2 and K60N512Z processor. It seems that when continuously reading from a large enough buffer of the interrupt driven driver, we are missing some characters once an hour or so. Data is coming continuously in the said port from an external modem.

Is there a possibility that since the UART5 has only one single FIFO register, there is a possibility that we can miss characters between reads?
Best Regards
Vinod Ganesh

[Cdn_aye]

Hi Vinod

The problem we had was we were not using the RS-485 version of the driver, therefore we had a lot of trouble finding out when the stream had ended and when a char was available. For example did the char get missed because it wasn't sent or we weren't looking at the right time?

Also this may be obvious but you have to use the interrupt driven driver, not the polled char driver. Without this char's get missed. Our personal experience is the polled driver implementations are a source of eventual failure. If the system gets busy and you miss a char your software could hang or fail because the stream does cause a correct decision. If you are just typing out text it doesn't matter as much as if you are parsing and using the stream in a switch statement for example.

You can set the buffer size in the user_config.h so I don't think that is the problem is the buffer. We found missing char's to be a serious problem and didn't really find a software solution to it therefore on our latest board change I added the RTS & CTS signals to implement the rs-485 protocol. I am hoping this will fix the issue; but I am not sure as yet because we haven't had time to make the software change. What we did as a software solution was run the port very slow and force large time delays between streams of data, then if a time out (we have an mqx timer) occurred we knew to discard the stream or terminate it.

Robert Lewis

[brianpaterson]

Robert,

Could you post the definitions for your variables as well, please?

I had a similar problem and it was in the definition of the buffer pointer (pca_rx_buffer).

Checking the other vars cannot hurt. '

Thanks,

Brian

[Cdn_aye]

Hi Brian

Here is the entire code segment. The pca_rx_buffer is a pointer to the char array which is passed to this function.

Regards

Robert

[DavidS]

Hi Robert,

After you send your stream of characters can you break and look at your serial task and see how many interrupts were processed?  Hopefully it is the same number as characters you send.

That might help to see if the translation stuff is messing up someplace and help to determine if the characters were seen in the interrupt at least.

Here is a picture of my serial task with Variable window opened on the int_io_dev_ptr.  Note I had to re-cast the DEV_INFO_PTR to "KUART_INFO_STRUCT_PTR" to look at the RX_CHARS variable that is incremented each time a receive serial interrupt occurs.

Regards,

David

[brianpaterson]

Hmmm....

After some trial and error, it seems that the delay time may be biting you.

OK, some basic stuff:

Characters are transmitted generally in a stream and generally at whatever baud rate and generally contiguous.

Cool. But note the "generally".

However, there is slop in the system. This is where the transmitting device pauses, ever so slightly, and then resumes (CPU gets an interrupt for example).

Well the CPU may not pause and transmit faster than you think. So the delay time is now skipping too far into the future.

I would try a shorter delay (much shorter) or buffer more characters in the incoming device.

You seem to be skipping characters on the leading edge of the transmission, correct?

At least, I did when I coded in your routine.

Thoughts?

[Cdn_aye]

Hi Brian

Here is the entire code segment. The pca_rx_buffer is a pointer to the char array which is passed to this function.

Regards

Robert

[Cdn_aye]

Sorry for the belated reply. In looking back a my posts and others, this was never solved. We just keep bumping up against the same problem and reposting. By using various empirical time delays the problem gets kludged around and works for a time until the next time we see that the problem happens.

Is the only solution to use RS485 signals and redo the layout to allow CTS and DTR control.? This is extreme but I do not see any other solution.

What I find odd is that this is a problem to begin with. Other OS's I have used simply return the buffer when it is complete, complete being defined by a break in the transmission. The work I have done so far with the UART seems to require either writing a new uart driver or guessing at the stream conclusion with timers. I agree with Brian; this is consistently what we see... missing first char's. But what is the solution? Is there a DMA mechanism that can be linked to the UART driver to make it work. Or is there a very simple issue we are missing.

Robert