Objective Development Forums

Re: [solved] Problems at some modulo 8 byte boundary

2011-09-20T09:52:59+02:00

Small note, you're better off not using the Arduino libraries if you want to be in control of your AVR.

The avr-libc library provides quite a few functions to help you on your way. And using hardware registers is a lot faster then using the Arduino libraries. (avr-libc is included and used by the arduino libraries, so you can just use it from your arduino environment)

_delay_ms: http://www.nongnu.org/avr-libc/user-man ... delay.html
Delays a number of milliseconds by busy waiting. Main issue is that you need to give it a static number of milliseconds to wait. So if you want to wait a variable number of milliseconds you need to put it in a loop.

Statistics: Posted by Daid — Tue Sep 20, 2011 9:52 am

Hardware problem? Timer!

2011-09-19T23:53:05+02:00

You were right about the 3v9 zeners are not the problem. I replaced the cut open cable with a B plug and a high speed certified cable, but still no luck. Even tried voltage dividing as seen on http://forums.obdev.at/viewtopic.php?f=8&t=1352&start=45.

It turned out not to be a hardware problem at all. Went back to Arduino's serial console and glanced at my code. I spotted that I did not reset the watch dog timer. That did not turn out to be the problem, but it paved the way to investigate timers. Project http://www.obdev.at/products/vusb/hidkeys.html sets TCCR0 to 5. Not yet knowing what it does, I just inserted it into my code, but the compiler hit me on the head. Googling led me to http://arduino.cc/forum/index.php/topic,3356.0.html and the quote

Timer0 is used for the Arduino millis and delay functions defined in wiring.c. Try timer1 or timer2.

More googling lead me to http://code.google.com/p/vusb-for-arduino/source/browse/libraries/UsbKeyboard/examples/UsbKeyboardDemo1/UsbKeyboardDemo1.pde about BYPASS_TIMER_ISR. Rewrote my existing use of delay() with a custom delayMs(), et voila.

Conclusion: my problem was timer related. I do not have much of a clue why and how, but that is not an issue for this thread. Case closed. Thanks for your time.

Statistics: Posted by gamut — Mon Sep 19, 2011 11:53 pm

Re: Problems at some modulo 8 byte boundary

2011-09-19T16:28:23+02:00

My USB cable is somewhat homebrew; abused an old standard cable (fullspeed max), soldered wires to pins for breadboarding. Could this be the problem? If there is too much interference (because of unshielded pins), the "illegal byte sequence" reported by wireshark makes sense.

I had an old mouse cable soldered to a board, which caused a lot of problems. I had a broken A-B cable soldered to another board, same problem. I shortened the cables, which solved the issue (10cm). But now I'm just always putting B connectors on my boards. So I can use A-B cables.

I've been using the 5V variant (without zeners, just a bit beefier resistors) without problems. So I don't think you'll run into problems because of the 3v9 zeners.

Statistics: Posted by Daid — Mon Sep 19, 2011 4:28 pm

Re: Problems at some modulo 8 byte boundary

2011-09-19T13:47:54+02:00

I though I bought 3v6 zeners, but the zeners are labeld 3v9. This might be the source of my problem. Am I outside the specs with 3v9 zeners? Can anyone confirm the wrong zeners would explain my errors?

* FWIW 1: I built "Solution B: Level conversion on D+ and D-" as per http://vusb.wikidot.com/hardware.
* FWIW 2: Without the USB Host Shield I still run into problems; the USB Host Shield is not the problem.
* FWIW 3: I am using the Arduino Uno rev2, which is powered by an ATmega328p.

Statistics: Posted by gamut — Mon Sep 19, 2011 1:47 pm

[solved] Problems at some modulo 8 byte boundary

2011-09-19T23:53:22+02:00

In short:
* My hardware: Arduino, runs at 16MHz, with USB Host Shield, and with VUSB
* My intention: create an USB proxy
* My problem: My response to GET DESCRIPTOR from VUSB to laptop fails.

If my laptop asks for either the device descriptor of configuration descriptor (haven't tested other descriptors), wireshark reports
URB status: Illegal byte sequence (-EILSEQ) (-84)

But is it not always the case. Also, the "URB length" and "Data length" that wireshark reports, have all been 0 modulo 8: I have seen 8, 16, 48, 80, 104 bytes.

I believe my debugging output it not taken up too much time. The USB 2.0 spec in 9.2.6.4 "Standard Device Requests" allows for 500ms to complete the configuration descriptor (if I read incorrectly it is 50ms). Wireshark timing example (for a 104 byte one):
Time delta from previous captured frame: 0.180987000 seconds

My USB cable is somewhat homebrew; abused an old standard cable (fullspeed max), soldered wires to pins for breadboarding. Could this be the problem? If there is too much interference (because of unshielded pins), the "illegal byte sequence" reported by wireshark makes sense.

The Arduino runs at 16MHz which is not that suitable for VUSB (according to the assembly and readmes). If VUSB runs out of sync, the "illegal byte sequence" reported by wireshark makes sense. Could this be the problem.

VUSB is connected to Arduino pins 2, 4 and 5. If I read correctly, it uses the interrupt with highest precendence; I do not expect errors because of servicing other interrupts.

FWIW #1: I use custom USB_CFG_DESCR_PROPS_* in usbconfig.h [(USB_PROP_IS_DYNAMIC | USB_PROP_IS_RAM)]
FWIW #2: I already replaced the code asking for the configuration descriptor via the USB Host Shield with a static configuration descriptor (but still via USB_PROP_DYNAMIC and _RAM). This does not solve the problem. It seems that the USB Host Shield is not failing me.

Can USB_CFG_HAVE_MEASURE_FRAME_LENGTH=1 and usage of usbMeasureFrameLength(void) be of any help?

My biggest problem is that I do not know what would be a good starting place for debugging and I am not sure what the foremost suspect is. Just some pointers would probably help a lot.

Statistics: Posted by gamut — Mon Aug 22, 2011 10:39 pm