STM32F4 multirole USB device

[Lukasz Przenioslo]

Posted on November 17, 2015 at 16:11

Hello there,

I am using STM32F407 with HAL library. I am trying to have following functionality on USB:- FAT system on a connected SD card through SDIO,- Bootloader.Ive been told to look at DFU. The problem is I am not sure how to look at this when interfacing STM32F4. In MxCube I could select DFU, Mass storage and etc when USB is only in device mode. But I thought- Dont I need dual functionality USB device? Like FAT system + virtual com port, for example to send a command to the MCU to jump into bootloader mode (which would have DFU functionality maybe)? The problem is CubeMx doesnt support dual USB mode configuration, is it hard to set it manually?I would apreciate help in this case, maybe someone has a better idea of how to do this? Basically In this MCU I need 2 features to be possible through USB:Mass storage device in connected SD card and reprogram option.

[romanetz4]

Posted on November 19, 2015 at 14:54

With MSC (Mass Storage Class) host orders USB device to only read or write sectors. Due to this reason, smartphones or music players turn off internal access to the file system - to maintain filesystem consistency. Additionally, using MSC, host is not limited to FAT, it can even reformat SD card into the ext4 or ReiserFS or whatever else. Device only needs to write or read sectors of 512-byte size. You should use MTP (Media transfer profile) class to operate at filesystem level. This allows simultaneous access from both embedded task and from host.

So, your device could be composite device with MTP+DFU class.

[romanetz4]

Posted on November 19, 2015 at 14:59

Composite device is not something impossible but requires much attention to modify standard examples. Different functions could be separated at interface level. 

[Lukasz Przenioslo]

Posted on November 21, 2015 at 21:41

I am not sure if this wworks the same way it was with AVR chips (I think it does because it makes sense, please corrent me if I am wrong)- With AVR there was a special sector dedicated for bootloader program. If I wanted to reprogram flash, I had to firt jump to the bootloader section. Otherwise, it would be impossible for an application to rewrite its own code. Thats why, I need DFU in bootloader section and mass storage device in program section. Futhermore:

When MCU is in application section, it needs to be able to write data to the SD card and the sd card needs to be visible through usb on the PC- is that possible? I wanted to write logs to that sd card and read them through mass storage.Second thing, while MCU is in application mode, it needs a trigger to jump to the bootloader section (the hardware one or a separate one with DFU?). I cannot use boot0 or boot1 buttons, it needs to happen by a command through USB. Since I only got the mass storage device, maybe I could create a certain file and save it on the sd card from the pc. When the MCU sees that file it can jump to bootloader- would that be technically possible? This way I would only need mass storage in application mode and DFU in bootloader mode.I would apreciate all help!

[Tesla DeLorean]

Posted on November 22, 2015 at 00:43

MSC devices emulate the SCSI command structures used by HD, CDROM, etc type drives.

One would presumably just create some other out-of-band/vendor specific commands that the device then handles specially. On the PC side you'd open an IOCTL channel to the underlying driver stack (port, or filter drivers) and send down SCSI commands or USB URB's. The commands could be used to change modes, or deliver the update. As the chip has a built-in System Loader that supports DFU, one could reboot into that. As I recall the original ST-LINK acted like a MSC, and the JTAG/SWD functionality was implemented with vendor commands. The MSC portion spoofed a small drive, with files pointing to web links. On products with SD Cards, you can place update binaries on the medium with specific names/directories, and those get picked up when the system boots.

[Lukasz Przenioslo]

Posted on November 22, 2015 at 22:05

''

On products with SD Cards, you can place update binaries on the medium with specific names/directories, and those get picked up when the system boots.''

Yes that is exacly what I would need! So is for example this possible:- MCU boots and starts in bootloader section, it checks the cd card for update. If there is none, it boots to application with usb mass storage functionality.Can the default bootloader do that or do I need to write my own?

[Tesla DeLorean]

Posted on November 22, 2015 at 23:22

The System Loader in ROM has rather limited abilities, mainly because it has no knowledge of the external system you've built around the chip. ie crystals, external memories, etc.

A loader that checks the application space for validity, and checks the MicroSD media, can be fit into about 16 KB, basically needs SDIO code, and FatFs in READONLY mode. You can check if the app on the card is newer/different than the one in flash, or the app can reset into the loader, flagging that it should erase/replace the current app. A build with write functionality could delete the file after a successful update. FatFs is probably overkill, I've built loaders that pull files into RAM, with much simpler sector/cluster chasing code that navigate the FAT structures directly.

[Lukasz Przenioslo]

Posted on November 23, 2015 at 08:06

Well, I have the SD card on the system anyways. Also, the code would not fit in ram, it can be a lot bigger because flash is 1 MB and RAM is only 168k in stm32f407. But in this case I would need to write 2 applications- bootloader + actual application. Maybe in order to use the default bootloader instead of writing it, I could send a command in mass storage mode (main application) to tell MCU to reset itself to default bootloader mode (thats possible right?). Then the default bootloader as far as I remember has USB interface so I could pick it up from there on the PC for programming. The question is, do I have to power cycle after programming or will it jump to the code automatically?

[romanetz4]

Posted on November 23, 2015 at 10:29

Note that default bootloader doesn't support encryption at all. You will have to transfer firmware over USB in open form.

[Tesla DeLorean]

Posted on November 23, 2015 at 14:51

You're wearing your STM32 hat a bit too tightly. Techniques are applicable and portable across many embedded platforms. I have an STM32 boot loader that flashes from a MicroSD, can nuke the app space, and enter the System Loader's DFU mode. All very doable.

I've discussed the execution of the System Loader without using the BOOTx pins multiple times on the forum. The connection/disconnection of USB is something you'll have to experiment with.