CODEWITHSUNDEEP
pythonlinuxserial-portpyserial
Travis Griggs
Travis Griggs

Reputation: 22252

Weird (py)serial linux corruption

I have a Linux SBC based on the Atmel SAMA5D36. I have another device hooked up to it via /dev/ttyS2 via TTL lines (115200 8N1). Using pyserial, I have a pretty high bandwidth query/response conversation with that device.

Periodically (at least once a minute), I see a very repeatable corruption of the date coming back from the other device. If it were to respond with some text like

"123456" (ascii character values)

It will drop one character AND add character-0 after the following character:

"13\x00456"

Hopefully that's clear. It will drop the 2, the next character is as expected, a character-0 follows, and then back to normal.

I am using kernel 4.1.10. Via some debug statements, I'm pretty sure this is not happening in my python loop, because the 0's show up in random spots of the read() buffer. I have also hooked up a scope on the incoming lines and have verified that the wire is not carrying this corruption.

I am looking for an answer that can get me in the right direction of figuring out why this is happening. CPU load does seem to increase the frequency (for example, when I'm doing a bunch of DBUS traffic for a BLE adaptor attached).

Upvotes: 3

Views: 464

Answers (1)

cajjed
cajjed

Reputation: 113

This could be a result of overflow errors. If you look at atmel_serial you can see if there are any errors.

cat /proc/tty/driver/atmel_serial

For example on ttyS2 you might see something like this (oe: shows the overflow errors):

2: uart:ATMEL_SERIAL mmio:0xF0020000 irq:31 tx:266758 rx:361385 oe:51 RTS|DTR|DSR|CD|RI

Since you are high rate serial you might try implementing DMA on the USART lines. Tweak the appropriate dts file in your kernel by adding the following to your usart settings:

atmel,use-dma-rx;
atmel,use-dma-tx;

For my kernel, I had to disable SPI and I2C so that there would be enough DMA channels available for the USART.

Upvotes: 3

Related Questions