Problem with UART on the BBB

GoogleGroups
1

I am facing a problem with lockup when trying to receive data at 115200baud on the BeagleBone Black:

For testing I’m using minicom to open the /dev/ttyO2.

ttyO2 was created with the supplied BB-UART2 tree.

What happens is that when data is sent to the BBB the first line och ascii-data shows up in minicom. But after that everything freezes, until I stop sending data to the BBB. (Even hdmi stops working)

I don’t know how to solve this issue. Any idéas?

Best,
Andreas

2

Can you send the schematics showing the drive buffers you are using? The distance would also be good to have.

Gerald

3

Hello Gerald!

I'm just sending the data from my FPGA and it is connected as a cape.
Worked perfectly on the BBW. So the distance is only a 1-2cm.
http://flighttronics.se/wp-content/uploads/2013/04/shx1fpga_top.jpg

Best,
Andreas

4

According to your pin mapping: http://xc2c256-cpld-cape-for-the-beaglebone.googlecode.com/files/CoolRunnerII_CPLD_Pin_Numbers_List_RevB.pdf your using uart5 on P8, not uart2.

Uart5 shares pins with the HDMI plug - did you disable HDMI on the board?

5

No that is not the same project! :slight_smile:

It’s a new fpga board now. http://flighttronics.se/wp-content/uploads/2013/04/shx1fpga_top-1024x557.jpg

But I’m just migrating from the BBW to the BBB.

But I think I got it now…

If the BBB can not sync on your streamed data it will lock up the operating system. Probably the same if it loses the lock.
I stream data @ 460800 baud with a data rate @11025 so there are should be plenty of room for sync between the bytes. That worked nicely on my BBW but not on the BBB.
Now I have to make a pause for a few bytes and then transmit the data.

/Andreas

6

This issue is very reminiscent of a serial port issue that occurred in the early days of SYSV rel 3 on Intel. What would happen was if the baud rate was high enough, the interrupts would occur so frequently that the kernel would be preempted which would cause the OS to hang. The fix at the time was to throttle the data within the device driver. That worked well enough. When processors got faster and buffered UARTs were used, interrupts were no longer a problem but that code remained…until the day when we were testing POSIX compliance on SVR4 on a SMP 486 machine. Proper throughput could not be achieved. The fix was simple once the developers knew where to look.

richard