libusb based program runs into problems

[jwatte]

I have an Atmega32u4 based microcontroller, driving a number of servos for a walking robot.

This works fine running Arch Linux on an Intel based PC. It uses basically no CPU, just sits in a loop to delay, issue a read and a write request, delay, ...

On Raspberry Pi model B version 1, using Arch Linux, this program just sends a few packets (about a dozen) before it seems to get wedged, and the same packet is being returned over and over again from libusb. After a second or so, an additional packet may be returned.

I do not have a USB bus analyzer, so I can't tell for sure what's happening on the USB bus, but it feels a lot like either a hardware controller lock-up, or a usb driver problem. It could, of course, be my own problem -- I wrote both the Atmega firmware, and the program talking to libusb on the RaspberryPi, so there's plenty of area for mistakes -- but as I said, it works fine on Intel.

Are there known problems with the USB hardware or driver on the RPi? Is there anything in particular I should look out for when trying to debug this problem?

Here's the output of lsusb:

Code: Select all

[root@alarmpi Onyx]# lsusb
Bus 001 Device 002: ID 0424:9512 Standard Microsystems Corp. LAN9500 Ethernet 10/100 Adapter
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 003: ID 0424:ec00 Standard Microsystems Corp. 
Bus 001 Device 004: ID 050d:0304 Belkin Components FSU304 USB 2.0 - 4 Ports Hub
Bus 001 Device 005: ID 050d:945a Belkin Components F7D1101 v1 Basic Wireless Adapter [Realtek RTL8188SU]
Bus 001 Device 006: ID f000:0002  
Bus 001 Device 007: ID 1781:0c9f Multiple Vendors USBtiny
[root@alarmpi Onyx]# 

Other attached devices include a wireless USB network adapter, and a USB programmer for the Atmega. The network adapter is sending/receiving a stream of UDP packets while this is going on, which may be related? It looks like the two usb ports are actually just an on-board hub for a single port on the RPi, is this a true observation?

[jwatte]

Slight update: The "return the last packet" part is actually just "the remote device sends single-byte dummy packets because no command has been received."

I would expect this to be a timing bug in my own code provoked by the different CPU, but I haven't yet found it, so any information anyone might have on specifics of the USB controller and device drivers of the Pi might be helpful to this bug hunt.

[jwatte]

Hey, don't everybody answer all at once, you hear?

The same program, sitting idle and just polling the Atmega, runs fine on Intel, but runs into trouble when running on the Pi. Typically after a minute or two, doing between fifty and two hundred polls a second.

Is the USB register-level interface documented for the Pi?

[ghans]

Did you have a look at the "USB Redux" thread ?
In the Bare metal forum , people are discussing the unofficial
USB Document , which has been made by contribitors.
Synopsys won't give the real datasheet to everybody who asks.


ghans