USB Interupt IN message length sometimes reported incorrectly

The RISC OS USB stack, as used on the Iyonix and the BeagleBoard, sometimes over-reports the length of interrupt IN transfers. This has been the case for a long time now. The current versions exhibiting it are 5.18 (16-Jan-12) on my Iyonix and 5.19 (12-Jun-12) on my BeagleBoard xM, but I saw it last year during my previous Bluetooth experiments.

Below is an edited trace of a series of transactions with one Bluetooth dongle (I have three different ones, which all show up the same problem). Each pair of lines with “Before:” and “After:” comes from a call to the function that reads interrupt IN messages when there are enough bytes available (I call it far more frequently, of course, but mostly there are no or not enough bytes available), before and after I read the bytes from the stream with OS_GBPB 4. The first number is the monotonic time. The second number is EXT# of the interrupt IN stream. The calls are in pairs: the first reads 2 bytes, of which the second is the number of bytes to follow. The second call collects the remaining bytes. The message content is then printed in hex.

Before: 604818: 6
After:  604818: 4
Before: 604818: 4
After:  604818: 0
0E 04 01 43 0C 00 

Before: 604819: 14
After:  604819: 12
Before: 604819: 12
After:  604819: 0
0E 0C 01 01 10 00 03 A6 07 03 0A 00 A6 07 

Before: 604819: 12
After:  604819: 10
Before: 604819: 10
After:  604819: 6
Suspect transfer: 6 bytes may be in error
Dumped 6 zero bytes
0F 04 01 01 52 0C 

Before: 604820: 6
After:  604820: 4
Before: 604820: 4
After:  604820: 0
0E 04 01 1A 0C 00 

Before: 604820: 6
After:  604820: 4
Before: 604820: 4
After:  604820: 0
0F 04 01 01 52 0C

Before: 605850: 6
After:  605850: 4
Before: 605850: 4
After:  605850: 0
0F 04 00 01 19 04 

Before: 605860: 16
After:  605860: 14
Before: 605862: 255
After:  605862: 0
07 FF 00 4E 97 CB D8 E7 38 44 61 76 69 64 27 73 
20 44 65 73 69 72 65 00 00 00 00 00 00 00 00 00 
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
00 

Before: 606013: 255
After:  606013: 253
Before: 606013: 253
After:  606013: 249
Suspect transfer: 249 bytes may be in error
Dumped 249 zero bytes
0F 04 00 01 05 04 

Before: 606133: 13
After:  606133: 11
Before: 606133: 11
After:  606133: 0
03 0B 00 2A 00 4E 97 CB D8 E7 38 01 00

As (I hope) you can see, sometimes the length reported by EXT# is too high. The debug messages about “Suspect transfer” and “Dumped zero bytes” are evidence of my error mitigation strategy working. It is fortunate that, in the case of Bluetooth, the first byte of an interrupt IN message can never be 0.

I like the case above, where it reports 255 available, then 0 after the 255 bytes have been collected – and then it goes up to 255 again, although 249 of them turn out to have the value 0 and are therefore identifiable as not part of a genuine message and are dumped.

On the other hand, the many zeros in the 257-byte transfer shown above are genuine.

I can usually spell Interrupt correctly. Honestly.

How is the value of EXT# of a stream passed from the USB drivers to a calling programme? I don’t have any picture of the layers within RISC OS and how they call each other.

How is the value of EXT# of a stream passed from the USB drivers to a calling programme?

I believe EXT will just return the number of bytes currently in the DeviceFS buffer.

usbmodule.c contains the code that sits between the USB driver and DeviceFS. Specifically you’ll want to look at the code in read_cb() which adds padding bytes to received data iff:

• The received length wasn’t an exact match for the requested length
• The received length isn’t a multiple of the endpoint max packet size
• The padding behaviour hasn’t been disabled

For bulk transfers the padding code generally behaves itself, but since the BSD code treats interrupt transfers as “repeating” it wouldn’t surprise me if this is causing some of the problems you’re seeing. But the bottom line is that you should be able to disable the padding code entirely by adding “nopad” to the filename special field when you open the endpoint (assuming you’re using USBDriver 0.49 or newer).