I'm doing some debugging, trying to get my USB code to work, (I'm having a problem with the tick timer not working...). When I came across an apparent contradiction in the TI code. Perhaps it may help the TI USB team (and might eventually help me debug my code).
The contradiction became visible in the function USBDHIDCompositeInit(), which says:
// Register our tick handler (this must be done after USBDCDInit).
InternalUSBRegisterTickHandler(...);
However, USBDHIDCompositeInit() is called before USBDCDInit(), not after, hence the contradiction. The TI comment is warning us of something, but the TI code itself does not obey the warning.
So I looked further. It appears the timer TickHandler gets registered, and then immediately zero'd out.
I here document the collision with pseudo-code snippets all from the Starterware package:
USBDHIDInit(...)
{
.
.
.
USBDHIDCompositeInit(...);
USBDCDInit(...);
}
Notice the sequence of those function calls. Next I'll expand those in the same sequence.
USBDHIDCompositeInit(...)
{
.
.
.
// Register our tick handler (this must be done after USBDCDInit).
InternalUSBRegisterTickHandler(...);
}
USBDCDInit(...)
{
.
.
.
// Initialize the USB tick module.
InternalUSBTickInit();
.
.
.
}
In other words, the following two functions get called in this sequence:
InternalUSBRegisterTickHandler(...)
{
g_pfTickHandlers[ulHandler] = pfHandler;
g_pvTickInstance[ulHandler] = pvInstance;
}
InternalUSBTickInit()
{
g_pfTickHandlers[ulLoop] = 0;
g_pvTickInstance[ulLoop] = 0;
}
The first function registers the tick handler, and the second undoes it (by zeroing it out), so the tick handler is no longer registered and can no longer function.
Only a little further in this same routine, it disconnects the USB device, then waits 100 milliSeconds (using the tick handler), and then reconnects the USB device. In my case, it never returns from the 100 milliSecond wait because the tick handler is not working. At least, that is my understanding of it.
Am I mistaken here?
