serial gateway overrun error ?

[rozpruwacz]

Hi all,
I just realised that i have a problem with my serial gateway communication to controller. My gateway is an atmega328p based custom board and my controller is raspberry pi 3. Gateway is connected to uart pins (gpio14, gpio15) of the pi, and the baudrate is 38400. This works most of the times, but sometimes i can see in the logs that only part of the message is received by the pi. Below the output of the miniterm.py program:
11;1;1;0;3;0 -> OK
11;1;1;0;2;0 -> OK
1␀1;1;1;011;1;1;0;2;1 -> NOT OK
when that happens the overrun error count of the ttyS0 increases by one:
sudo cat /proc/tty/driver/serial
serinfo:1.0 driver revision:
0: uart:16550 mmio:0x00000000 irq:166 tx:19902 rx:358134 oe:1046 CTS

So it seems that it is rather a problem with interrupt handling (the overrun error happens when the buffer is full and new byte comes in), and not with the hardware connection.

Does anyone had the same problem ? Is my assumptions that the problem is related to interrupt handling correct ?

[Yveaux]

@rozpruwacz what radio are you using, and if nrf24, do you have message queuing enabled on the gateway?

[rozpruwacz]

i'm using rfm69 but this is not the problem with the radio, because I use ack'ing. The node will keep resending every 2 seconds when no ack recevied. When the problem happens, for example when i turn lights off and the controller does not get the status update which should be sent by the node, I see in the logs that the status update was received by the gateway but on the rpi side i see only first byte of that message.

[mfalkvidd]

@rozpruwacz how is the custom board clocked? Maybe the uart timing is slightly inaccurate?

[rozpruwacz]

@mfalkvidd it is clocked from the internal oscillator and works on 8MHz. The clock may be a problem, but would it cause overrun errors in the kernel driver ? I now connected the gateway through the pl2303 uart<->usb converter and I'm waiting to see of it helps.

[mfalkvidd]

@rozpruwacz I guess it shouldn't. Maybe if one incoming byte is treated as two, but the kernel should still be able to process that I think. It would decode the byte incorrectly, but it shouldn't cause an overrun.