Documentation for USB MSC driver and details of RTOS support

[scottm]

I'm not finding any documentation that specifically covers the mass storage class driver included the MCUX SDK. Does this documentation exist?

It appears to be a continuation of the same Freescale driver I've been using for many years and now that I'm in the process of porting some projects from Kinetis to LPC55S69 I'm remembering some of the issues I've had in the past.

The big one is about the callbacks. If I recall correctly, at least some of those callbacks happen in interrupt context. For an RTOS-based system with the MSC driver hooked in to an external SPI flash memory the problem is that the SPI access is usually protected by a mutex. With the MCUX FreeRTOS SPI driver this is automatic. And of course you can't have the ISR waiting for a mutex so it can read data from flash.

I handled this before with a bunch of logic that includes suspending USB interrupts during non-interrupt SPI accesses, and switching between DMA and polled operation depending on whether it's in an interrupt.

I also remember a macro buried in the USB stack somewhere that'd let you keep some of the processing in a task, deferring processing from the ISR to the main loop or RTOS task. I also seem to remember that it didn't defer ALL callbacks and I don't remember if it existed it in all versions. Is that option there? Is there documentation on what things happen in the USB interrupt context?

Ideally I'd like to keep all USB interactions in RTOS tasks and not have any callbacks happening in interrupt context at all.

Thanks,

Scott

Edit:

I checked and the macro is USB_DEVICE_CONFIG_USE_TASK. Googling it takes me right back to a question I asked here 3 years ago.

The questions I really need answered are:

1. How do I properly use this option? What's the function I need to call and are there any other considerations I need to be aware of, like minimum task stack size?

2. Does this option guarantee that ALL class callbacks will happen in the task context and not interrupt context?

[ZhangJennie]

Hi scottm 

MCUXpresso SDK is free.The purpose of MCUXpresso SDK is to showcase NXP LPC functions. 

For user, we can only refer pdf files under SDK pakage\docs folder and readme.txt file under the demo code folder. besides, there is no other doc.

 The usage of USB_DEVICE_CONFIG_USE_TASK is explained in this thread by Daniel. FYI.

https://community.nxp.com/t5/MCUXpresso-SDK/Questions-about-SDK-2-3-1-USB-CDC-VCOM-Example/m-p/76217...

Thanks,

Jun Zhang

[scottm]

Hi Jun,

The purpose of MCUXpresso SDK is to showcase NXP LPC functions. 

From the MCUXpresso fact sheet (emphasis mine):

Created as a software framework and reference for application development with NXP’s Arm
Cortex-M-based MCUs, MCUXpresso SDK includes production-grade software with integrated RTOS (optional), integrated enabling software technologies (stacks and middleware) from NXP and its partners, reference software and more.

Maybe this is the source of our misunderstanding. Perhaps NXP marketing only means that some of the SDK is production-grade software? How do we tell which parts are production-grade software intended to be used in production, and which parts are mere demonstrations? I see no suggestion that the USB stack middleware is not intended to be used in real applications.

The usage of USB_DEVICE_CONFIG_USE_TASK is explained in this thread by Daniel. FYI.

It's not, really. Daniel only addresses the setting's effect on the context in which USB_DeviceCdcVcomCallback() is called. He doesn't describe how the option actually works and whether any other callbacks still happen in interrupt context. Keith specifically asks for clarification of whether USB_DeviceCdcVcomCallback() has to be modified to account for the different FreeRTOS function required to send to a queue from an ISR versus from a task, and Daniel ignores the question. Geoff calls out the lack of response and there's still been no follow-up.

How does this software even get created without a design document or specification? There are hundreds of lines of code relating to this configuration option and the entirety of the documentation we get for it is "/*! @brief Whether the device task is enabled. */". Someone put a lot of effort into writing the code. Presumably someone told them what they were supposed to be writing.

In USB_DeviceNotificationTrigger() in usb_device_dci.c we can see that USB_DeviceNotification() is called directly (without putting a message into the task's queue) when (0U != (message->code & USB_ENDPOINT_NUMBER_MASK)) && (0U == (message->code & 0x70U)).  This suggests to me that something is coming through in interrupt context but I'm not clear what.

So to reiterate my question, when the task option is enabled, what callbacks if any still happen in interrupt context? Without this information it's not possible to write an RTOS-safe application using the USB middleware.

Thanks,

Scott