usb Mass Storage.

I had a quick look at the USB mass storage several months ago, but from what I recall the old code didnt work.

However I didnt have time to work out why not, and I got the feeling that whatever the problem was, it probably would not be hard to fix.

With the HID USB stuff as well, I suspect we need to work out a USB strategy

RogerClark wrote:I had a quick look at the USB mass storage several months ago, but from what I recall the old code didnt work.

However I didnt have time to work out why not, and I got the feeling that whatever the problem was, it probably would not be hard to fix.

With the HID USB stuff as well, I suspect we need to work out a USB strategy

victor_pv wrote:RogerClark wrote:I had a quick look at the USB mass storage several months ago, but from what I recall the old code didnt work.

However I didnt have time to work out why not, and I got the feeling that whatever the problem was, it probably would not be hard to fix.

With the HID USB stuff as well, I suspect we need to work out a USB strategy

victor_pv wrote:
Quick update, I got it to compile over the weekend, but did not have time to wire a board to an sdcard and test it.
Hopefully next weekend…

libarra wrote:
<…>
That’s great! Could this help to make a bootloader version where you can upload the binary files by dragging them to the ‘storage’ device?
<…>

Agree with Ray. That’s why almost all manufacturers use a seperate MCU for drag-and-drop programing the main MCU.
Ofcourse, the additional chip acts as usb-to-serial converter and as a debugger also.

In the past, I used the ST-link for programing my stm32 boards. During the projects development I saw that I had to develop upto 4 simultaneusly projects. I forced to disconnect my st-link from the one stm board to the other one. That was too annoying. Because every stm board has a usb interface I finally decided to use the stm32duino bootloader by spending 8kBytes of flash memory for that.
It worths to use it because it doen’t consumes a lot of flash memory and CPU resources.

In my opinion, the current stm32duino bootloader is enough. The drag-n-drop feature is very good in case someone wants to design an another stm32 programmer such as ST-Link v2.1

mrburnette wrote:

Is this something the world really needs?

The implication is that a listening executable (or GUI scripting language) must be running in memory to accept the properties from the drag-n-drop action. Nothing comes free.

Ray

Maybe I missed something here, but drag’n’drop is implemented by file browser, not by the device itself.
if the device provide mass-storage functionality, and the command-line copy is working, then drag’n’drop will work too.

It remind me that when I’ve received a LPC1768 dev board several months ago, it already had such kind of MSC bootloader in it.

martinayotte wrote:Maybe I missed something here, but drag’n’drop is implemented by file browser, not by the device itself.
if the device provide mass-storage functionality, and the command-line copy is working, then drag’n’drop will work too.
…

martinayotte wrote:Maybe I missed something here, but drag’n’drop is implemented by file browser, not by the device itself.
if the device provide mass-storage functionality, and the command-line copy is working, then drag’n’drop will work too.

It remind me that when I’ve received a LPC1768 dev board several months ago, it already had such kind of MSC bootloader in it.

I used the mbed LPC ARM board some years back. It has drag-and-drop downloading.
As I recall:
The board has a second smaller microprocessor. It runs the USB mass storage support code, and it uses FATFS and a smallish SPI flash chip.
So a drag and drop actually causes the 2nd microprocessor to take the new file and store it in flash.
Then, IIRC, the 2nd micro installs that file’s code in the main processor if the date is younger than the last installed file (or there is no prior).

I don’t recall how the 2nd micro causes the 1st micro to get and self-program (write flash).

The reason for the 2nd micro was that it always worked, no matter errors in user code and using it adds cost but avoids diminishing the flash available to user code and it didn’t disrupt the reset sequence of the 1st micro from the defaults.

The Teensy 3 board (Freescale Cortex M3) has a 2nd micro too. It doesn’t use the scheme above as USB storage, but it does allow the primary MCU to not have special reset code/sequence, nor does it cost flash space. It could be drag and drop but instead it is invoked by the IDE (Visual Micro’s IDE (Visual Studio) or Arduino’s IDE). These IDEs are both supporting the ARMs from Atmel, Freescale, ST Micro and others.

The 2nd micro is low cost, like < $1.

In the case of the LPC1768 board I’ve mentioned, there was no second MCU, the USB Mass Storage was handled by it own bootloader.
Any files been written in the devices (via copy or drag’n’drop) was automatically updating the firmware without any validation.
http://www.ebay.com/itm/NXP-Series-LPC1 … 2a40642c05

I think Ray meant that you need to have code running in the MCU to detect when a file has been copied to the mass storage device, and write to flash.
Such code would consume Flash, RAM and CPU cycles, taking them away from the resources available to your application.
The flash usage may not be an issue, but the processing time it needs, just to be waiting for a file to be copied to it… That’s what the st-link is for. Your main MCU is fully devoted to your application, and a second MCU takes care of the communication and programming.
Also, if your code crashes the MCU, then the bootloader doesn’t work anymore.

Having the bootloader we have now I think is a better compromise. It only takes a few seconds of CPU time, then pass full control to your code, including full control of the USB port. If you code messes up the usb communication, you can press the reset button and the bootloader is listening again.

martinayotte wrote:In the case of the LPC1768 board I’ve mentioned, there was no second MCU, the USB Mass Storage was handled by it own bootloader.
Any files been written in the devices (via copy or drag’n’drop) was automatically updating the firmware without any validation.
http://www.ebay.com/itm/NXP-Series-LPC1 … 2a40642c05

martinayotte wrote:Maybe I missed something here, but drag’n’drop is implemented by file browser, not by the device itself.
if the device provide mass-storage functionality, and the command-line copy is working, then drag’n’drop will work too.

It remind me that when I’ve received a LPC1768 dev board several months ago, it already had such kind of MSC bootloader in it.

mrburnette wrote:I obviously misunderstood; I was thinking that an implementation such as:
https://www.pjrc.com/teensy/loader.html

Was desired and that it would be drag-n-drop active. Yes, one could use Explorer to store a bin just like any ol’ flash drive provided the device properties enunerate as USB mass storage.

libarra wrote:mrburnette wrote:I obviously misunderstood; I was thinking that an implementation such as:
https://www.pjrc.com/teensy/loader.html

Was desired and that it would be drag-n-drop active. Yes, one could use Explorer to store a bin just like any ol’ flash drive provided the device properties enunerate as USB mass storage.

On my old LPC1768, I had to press a Boot button at powerup to make it turned into USB Mass Storage.

I think we need to test if Windows 7 (and later) will allow multiple device drivers to be loaded against one piece of hardware.

AFIK, this was the main stumbling block for Leaflabs when they originally did the bootloader, but they were developing for XP

i.e You can’t run the Serial USB and DFU Drivers at the same time, because these are two different (internal Windows drivers), rather than a composite driver that commercial companies deploy to do this sort of thing on other boards.

I suppose its possible to write a composite driver, but I’m not sure who would have the time or skillset to do it, and even if someone did write one, the other problem is loading an unsigned driver, as the cost to sign a driver for Windows is AFIK, many thousands of dollars.
There may be a work around like the libwdi system to load a driver (sys) file, but its no something that I’ve come across.

So I think this is a bit of a distraction really and everyone’s time could be better spent on other things.

RogerClark wrote:I think we need to test if Windows 7 (and later) will allow multiple device drivers to be loaded against one piece of hardware.

AFIK, this was the main stumbling block for Leaflabs when they originally did the bootloader, but they were developing for XP

i.e You can’t run the Serial USB and DFU Drivers at the same time, because these are two different (internal Windows drivers), rather than a composite driver that commercial companies deploy to do this sort of thing on other boards.

I suppose its possible to write a composite driver, but I’m not sure who would have the time or skillset to do it, and even if someone did write one, the other problem is loading an unsigned driver, as the cost to sign a driver for Windows is AFIK, many thousands of dollars.
There may be a work around like the libwdi system to load a driver (sys) file, but its no something that I’ve come across.

So I think this is a bit of a distraction really and everyone’s time could be better spent on other things.