How to use STlink-V3 in mass storage mode to program bootloader and main program? How to continuously influence the address from which STlink-V3 programs the FLASH memory?

[vfura.1]

Hello, We are switching to STlink-V3 as our main debugging and programming tool. For programming, we use the mass-storage interface for simplicity. It works perfectly.

The problem is that the mass-storage interface programs the FLASH memory from address 0x08000000. It is not possible to simply change it.

At address 0x08000000 we have the bootloader.

At address 0x08010000 the main program starts.

For regular development and production programming, it is useful to be able to program both things with the simplest possible configuration.

By default, our original tool programmed from address 0x08010000 (main program). However, if the text file BOOTLOADER.txt was uploaded to the massstorage interface before the bin file, the programming was from address 0x08000000 (bootloader). Simple and elegant solution to program bootloader and main firmware. Simple for both programmers and scripts that control programming.

How can this be done on STlink-V3?

[Pavel A.]

Same question here.

Asked also on the ARM forum with tag 'mbed', hope somebody there has a clue.

[Piranha]

Formally this feature cannot be guaranteed to work at all, because noone can guarantee the order in which the "disk" sectors are written. If the updated FAT file allocation table is not written as the first one, then the debugger firmware cannot know the mapping of the file clusters/sectors. I wouldn't wonder if it doesn't process the file allocation table at all and just relies on the host writing the file in a linear manner...

[vfura.1]

Thank you for your answers. I understand that there may be technical issues, but we know from experience that these solutions can be fully functional in practice. We ran our old tool for several years and it worked perfectly (Windows, Linux, Mac + STM32F4xxxx). I think there should be a solution here.

Is there a way to get a statement directly from someone at STM?

@Pavel A.​  did you solve it somehow? Can you share a link to the arm forum?

[Bob S]

What if you use HEX files instead of binary? I haven't tried this for changing the starting/loading address, but I have used HEX files in general.

[Piranha]

RN0093 - Rev 28, section "3 Known problems and limitations", page 5.

https://community.st.com/s/question/0D53W00001OOiRUSA1/details-about-mbed-draganddrop-programming-with-stlink-using-usb-mass-storage-msc

[Bob S]

That doesn't say HEX files are not supported, only that they need to have valid FLASH memory addresses and a "file too large" error will not be detected until all of FLASH has been filled (I think they really mean until the HEX file attempts to write to an address past the end of FLASH).

I just tested with a NUCLEO-F749ZI running ST-Link V2.J38.M27. I can copy an Intel HEX file with data starting at 0x08100000 and it loads at that address and does not touch the existing program loaded at 0x08000000.