uPSD3234A USB Problem

thomasthanner9 · ‎2005-05-19

Posted on May 19, 2005 at 15:49

thomasthanner9 · ‎2011-05-17

Posted on May 17, 2011 at 12:06

Hi there,

we wanted to use a uPSD3234 device at 36 MHz to create a USB keyboard application. We are using the SDCC compiler. The uPSD is located behind a TUSB2046B hub on the same board. The hub is working just perfect.

We started development based on the latest (Feb-2004) sample driver code from the DK3200 EVA board. When we compile the original application everything works fine. But as soon as we start to change that application, especially when we remove the LCD and FLASH code, the deive is no longer configured by the USB. Not a single USB interrupt is issued after power up.

We have verified, that the USCL register has the right content. Tge hardware is ok, because the sample code runs on to different boards.

What we have observed so far is a very tiny timing window after power on reset when USB may be initialized. If we miss that window, there will be no USB functionality any more.

The problem is, that even defining some variables in XDATA can lead to timing window misses, due to variable initialization at power up.

Has anybody else made such bad experieces with uPSD3234 and USB?

Do we run into trouble because we use the SDCC?

Is anybody actually using USB on a ST3234 with 36 MHz and SDCC compiler?

Any kind of help or hint is more than appreciated! :D

thomasthanner9 · ‎2011-05-17

Posted on May 17, 2011 at 12:06

Thank you for the information. Meanwhile we could nail down the problem a little bit further.

The trouble maker seems to be the hub on the same board. Immediately after power up the hub set the controller into USB Suspend mode (as it should be). But in this case the uPSD does not accept suspend mode. The uPSD-USB-part never comes out of suspend mode in this case. When we connect the uPSD directly to USB it works. If we set the uPSD to suspend mode after the device was configured it woks, too. But if the uPSD is set to suspend mode before being configured by the host, the USB engine of the uPSD breaks down.

Has anybody some experiance with a uPSD behind a hub on the same board?

Thanks again for all kind of help!

thomasthanner9 · ‎2011-05-17

Posted on May 17, 2011 at 12:06

Problems solved :D

I got the controller running, even behind my hub!

It looks like the configuration phase of the USB is very critical for the uPSD3200. Care has to be taken to be ready for configuration after a very short time after power up. To achive this goal I had to make some minor changes to my hardware and to my software flow:

The pullup at USD_DM is no longer connected to +5V, but to the output of the RESET generator instead. This will delay detection of the uPSD by the Hub until the RESET=LOW periode is over (approx. 300ms for a LM809 reset generator).
Right at the beginning of main() I do only the important USB initialization stuff, as fast as possible, enable interrupts and keep the watchdog disabled. Right after usbState is set to US_CONFIGURED I do all the other initializations and start the main loop. From now on watchdog operation is ok, too.
Finally I still have to take care when the call to usbInitialize is done after power up. If it takes too long, or even if it comes too fast, USB will not work. Even a change in the number of global variables will have an influence, since the compiler startup code initializes all of them. So the number of variable to initialize has an influence on startup time. Why it is dangerous to be too fast is not quite understood, yet. My favorate hypothesis is that I am always too slow to catch the first configurtion try and have to time startup to be able to catch at least the second one on time. If I am too fast I will get a partially configured device. And that is something the example USB driver cannot handle.

I hope my findings are helpful to other, too. Now I have a full week of vacation and I will enjoy it as much as possible 😉

Greetings, to all!

gj2 · ‎2011-05-17

Posted on May 17, 2011 at 12:06

segafredo

I know this is too late to help, but otehrs may find it useful that we too found the USB required immediate servicing after power up. We have had to delay all other items whilst the USB enumerates and then can allow it to continue. Interestingly this is a bit of a problem with the with the ST library code for EEPROM emulation, which turns off interrupts whilst writing to the flash - we found that we could not call the init routine too soon after power up.

I like your hardware mode to buy yourself some more time. For information we are using the internal reset source and have not had any problems than just dedicating some time to the USB interrupt routines early in our code. We have not found the number of variables to be a problem either.

Regards.