USB Device - dynamically choose interfaces

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

USB Device - dynamically choose interfaces

1,148 Views
brunoalbrecht
Contributor III

Hello,

I have an application running FreeRTOS and USB communication (acts as a Device). My objective is to have one Virtual COM port and on Mass Storage Device over the same USB (composite device), where the MSD should NOT show up automatically. The user can ask through VCOM Port for the Disk to appear or disappear.

I used one of the examples (usb_device_composite_cdc_msc from SDK 2.3.0 for MK22FN512VLH12) as a base for my application, but I don't understand how to control when the interface should appear, which functions to call, etc.

Can anyone point me to the direction?

Cheers,

Bruno

Labels (1)
Tags (2)
0 Kudos
6 Replies

843 Views
mjbcswitzerland
Specialist V

Hi Bruno

I have attached a video showing possible operation as you wish.

I simply inform that there is no card inserted and after a short time I inform that a card 'is' inserted and then the disk drive "appears" (about 0:22 in the video).
If you look carefully, the disk drive does appear for a fraction of a second when the USB device enumerates but then disappears again.
As shown in the video the composite USB-CDC operates normally during the period.

Regards

Mark


Kinetis: http://www.utasker.com/kinetis.html

USB: http://www.utasker.com/docs/uTasker/USB_User_Guide.PDF
USB composites: http://www.utasker.com/kinetis/USB_Device.html
USB-CDC host<->device video: https://www.youtube.com/watch?v=XhISV1czIo4&list=PLWKlVb_MqDQFZAulrUywU30v869JBYi9Q&index=16

Free Open Source solution: https://github.com/uTasker/uTasker-Kinetis
Working project in 15 minutes video: https://youtu.be/K8ScSgpgQ6M

Professional Kinetis support, one-on-one training and complete fast-track project solutions: http://www.utasker.com/support.html

0 Kudos

843 Views
brunoalbrecht
Contributor III

Hi Mark,

Very nice, that's basically the kind of feature I want to implement. My application, though, is written using FreeRTOS and NXP's USB stack.

Can you explain how you didi it? Or at least what should I look for when searching for this info? I tried "detach" or "disconnect", but most results were about a Host connecting to a device.

Cheers,

Bruno

0 Kudos

843 Views
mjbcswitzerland
Specialist V


Bruno

The behavior/control has nothing to do with FreeRTOS - I can do the same with existing FreeRTOS projects - but it is the USB MSD class/file system that actually influences it.

Do you use an SD card together with the MSD? In this case you will need to understand how the FAT and MSD interact together - since I can't help with the NXP stack or fsFAT you will need to either study the details to work it out or request support from the individual sources.

In the uTasker case (which is a complete integrated solution and not a collection of libraries from different sources) [it is also free and open source] it is done by controlling the MSD class responses to various UFI requests - for example, the host will usually be polling the state of the disk and so one place to make it dependent is there (although the host will also request some other card details at enumeration, such as format capacity, where similar "unusable" states need to be returned).
Eg. this is the response to the sense request:

    case UFI_REQUEST_SENSE:
        {
            CBW_RETURN_SENSE_DATA present_sense_data;
            uMemcpy(&present_sense_data, &sense_data_OK, sizeof(sense_data_OK)); // prepare positive response
            if ((ptrDiskInfo[ucActiveLUN]->usDiskFlags & (DISK_MOUNTED | DISK_UNFORMATTED)) == 0) { // if the disk is not present
                present_sense_data.ucValid_ErrorCode = (CURRENT_ERRORS); // set that the disk is presently in a non-usable state
                present_sense_data.ucSenseKey = SENSE_NOT_READY;
                present_sense_data.ucAdditionalSenseCode = DESC_MEDIUM_NOT_PRESENT;
            }
            fnWrite(USBPortID_MSD, (unsigned char *)&present_sense_data, sizeof(present_sense_data)); // return the response
        }
        break;

so if one can control the LUN's disk state one can make MSD think that the disk is not inserted, and then one can set the state back to an inserted/formatted disk when one wants MSD to start working with the disk.
I just manipulated the ptrDiskInfo[ucActiveLUN]->usDiskFlags by adding a controllable mask to do it.

if (((ptrDiskInfo[ucActiveLUN]->usDiskFlags & usLocalMask) & (DISK_MOUNTED | DISK_UNFORMATTED)) == 0) { // if the disk is not present

so I can control it by changing usLocalMask between 0 and (DISK_MOUNTED | DISK_UNFORMATTED).

I assume that your MSD class has basic support for correctly handling disk state information, otherwise you will first need to expand it before you can start controlling it.

Regards

Mark

0 Kudos

843 Views
brunoalbrecht
Contributor III

Thank you very much for explanation. I understand now that the control whether the Disk "appears" is closer to the device itself (UFI request) and not something on the USB stack. I do have access and have customized the answers to such messages, thus I'll try this approach.

Regarding the disk, it's not an SD Card, but a Flash Memory IC soldered to the board (I don't want it to always show, though). I have whole interface between my software, the memory and the computer implemented (Flash memory driver, FAT FS implementation, answers to USB MSD requests, etc).

Could the same approach be used with the VCOM port? If so, which USB request should I check for?

Regards,

Bruno

0 Kudos

843 Views
mjbcswitzerland
Specialist V

Bruno

I don't know of a method to do it with VCOM - the Windows driver only really request the UART settings when connecting. You could study the USB-CDC class docs at usb.org to see whether there is anything that might help (like GET_COMM_FEATURE) but it may need a dedicated driver at the PC to actually make use of.

Regards

Mark

P.S. Which wear-leveling method do you use with the flash memory?

0 Kudos

843 Views
brunoalbrecht
Contributor III

Hi Mark,

thanks for the info. I'll check the class docs and if I find anything interesting, I'll post here for reference.

Regarding the wear-leveling method, I'm actually not using one. The flash memory won't be written too many times (I'm just storing some configuration for easier access from the user side).

Regards,

Bruno

0 Kudos