CCS/TM4C1290NCPDT: TivaWare USB callback function execution context.

Hi Ralph,

Thanks for the feedback and the sample code.  My question is: if the callbacks are not running in an interrupt context, then how does it get the program counter?  I'm not periodically calling any USB functions to give it.

Thanks, Doug

Hello Doug,

I don't think the USB callback functions ever need the program counter. They are honestly probably not named well. This was developed a long time ago and the nomenclature isn't always up to modern standards.

The callback functions are generally just used whenever something occurs to change data for whatever it is specified a callback for. For example the callback for an interface is used to change data for the interface configuration. It doesn't run on an interrupt but just every API that changes that type of data then fetches the callback and changes the data for it.

???  For any program to run it, ipso facto, must have the program counter to point to the instructions to run.

Hello Doug,

Sorry if I was unclear, what I am meaning is that they aren't needing to just take the PC out of the blue, and do not need to be 'given' the PC until they are used within functions like any other structure/buffer etc.. All of that happens inside usblib anyways. The callbacks are used within functions to pass data back and forth. The point is that there is no interrupt contexts to consider for them (beyond maybe being used within an ISR, but that's not the point here if I understand right). Not sure if that makes anymore sense, I'm not great at explaining how the USB library works at times since I didn't design it and it's architecture is... let's say, 'unique' and leave it at that.

Hi Ralph.

Unless I'm missing something, in a non-rtos environment there is only the thread of control from the call to main(), and asynchronous threads of control that happen in servicing interrupts.

Here's what I think is happening: the USB controller in the chip generates interrupts for various USB events, and also has its own "Sys Tick" to periodically run the stack, therefore I think that the callbacks have to be running in an interrupt context.  For now I'm going to assume that this is the case and keep my callback functions short, synchronize passing data and events to my "while(1)" loop, and do any heavy processing in that "foreground" process.

It still would be nice to know - if anyone out there knows - if the USB callbacks are running in an interrupt context.

Thanks, Doug

Anyone??  If my assumptions are correct, this really should be made clear in the documentation.

Thanks, Doug

Hello Doug,

For TI in the US we are on Good Friday holiday today but I will try and answer some more...

The initial question that was asked - to my interpretation - was asking if the USB callbacks listed were always running under an interrupt context within the usblib implementation. Therefore I was focused specifically on the interrupt context term in regards to thinking of them being called from an interrupt directly within the usblib without viewing it from a 'typical application' point of view.

So lets take a step back and break down library vs application.

In the USB library, the callbacks you mentioned are not executing exclusively under interrupt context. There are a few callbacks for disconnect, suspend, resume, low power etc. that are which can be seen in USBDeviceIntHandlerInternal.

From a typical USB application, many times interrupts are used to trigger reading / writing to USB buffers. This would be a scenario where the callbacks you referenced would be handled under interrupt context. This is defined at an application level and it depends on your implementation. You don't have to do this, but most time it is the best way and generally recommend. So within that setup, then yes it would be fair to now say the callbacks are handled in an interrupt context.

Sorry that my understanding of what you were asking was not correct but it was never clear to me that we were only talking about this from an application perspective which has variance on implementation.

Regarding documentation, because the interrupt context is based on the application, I don't see a documentation gap regarding this personally, but we may have to agree to disagree... this is the first time these questions have ever arisen.