UART data sliced in two piece ....


I would like to know if someone has experienced data sliced in two pieces ?

My case is simple, the UART in the beagleBone Black send the data in two piece …

The problem is that the device answer with an error crc …

so why the uart is doing that ?



You’re missing a bunch of information needed to help troubleshoot/ For starters how fast ? Which distro ? Which kernel driver are you using ? etc etc etc.


Well, the baudrate is at 38400, the distribution is the Ubuntu from Robert C Nelson ( 3.8.13 bone 30 ), the driver is the omap . I’ve modified a little bit the driver to add RS485 support ( see the patch attached ) , the only major modification that I’ve done is to add :

  • wait_for_xmitr(up);

  • if (up->rs485.flags & SER_RS485_ENABLED) {

  • if(up->rs485.delay_rts_after_send>0){

  • udelay(up->rs485.delay_rts_after_send);

  • }

  • /* Disable RS485 TX EN */

  • val = (up->rs485.flags & SER_RS485_RTS_AFTER_SEND) ? 1 : 0;

  • gpio_set_value(up->rs485.gpio_pin, val);

  • }

in the function serial_omap_stop_tx .

It works most of the time, but for an unknown reason there is this weird behavior …

Any tips ? lead to follow ?

rs485 (1).patch (8.41 KB)



Thanks for your answer,

Well, it’s just 16 octets or less … most of the time it works, but somehow the driver decide to interrupt the transfer …

yes it’s a single call to write …

Do you know if there is a configuration to solve this bug ? I’m also wondering if it’s because my linux ( 3.8 ) is not a real time kernel … maybe i should apply the kernel PREEMPT_RT ?

I’m really lost …


Problem Solved !

By disabling the preempt mode in the kernel config … I have some fopen call in my program which is not a good idea in real time application …

Thx everyone for the help !

Good to her Micka,

I had an idea that this was the problem ( thread was getting interrupted, and state not save properly etc ), but I’m a complete Linux programming newb so . . .

Glad to hear you got it resolved.