How to upload a software to STM32H745I-DISCO board from PC using ST-Link USB disk feature.

[HTD]

The project is made with STM32CubeIDE. Uploading from it is simple and works.

Then I used CubeProgrammer to upload .hex file. Also works.

But both require installation and configuration on the target PC.

However, the device is seen as an USB disk.

The problem is - the HEX file is too big to fit in there. Is there a workaround for it?

I tried to generate a BIN file, but it's 2GB - why? My whole project doesn't use that much data.

Here:

I need to send the update to someone that has the device, but no ST software installed. What are the options?

My plan B is to send them CubeProgrammer and HEX file.

BTW, HEX file is not the optimal in size. It stores the binary data as text, that use at least 3 times as many bytes as raw data. Why is BIN 2GB? It should be smaller than HEX. Is there any other format that could be used to flash the chip by just copying the file to that special "UBS disk"?

[Tesla DeLorean]

>>Why is BIN 2GB?

Because binary files can't be sparse (ie containing large voids), and describe memory at 0x08000000 up through 0x90000000, which is around half the 32-bit 4GB address space.

You'd need to break it into pieces, some of the better tools will do that.

Still the QSPI space is bigger than 4MB, and not supported by the ROM boot loader. It supporting the eMMC would surprise me.

You want to push something in, you're going to have to make a target side USB-DFU loader, that's aware of the QSPI memory, they pins and the type/size of device.

You could perhaps make a USB-MSC loader that's got awareness about .HEX or .ELF files.

Or you could use the ST-LINK/VCP and make a loader on the UART that can do X-MODEM from a terminal application.

[HTD]

I still don't understand why binary files can't be sparse (like sparse arrays in JS). It's just how every executable is: address, length, data bytes, in binary. It's probably how the HEX file works, but well, so either we treat bytes as text, or to place a byte at 0x0000 and another one byte at 0xFFFF we need 64kb? OMG, that BIN format is so useless.

So for now, as I need to push it tomorrow morning, I'll just stick to plan B, just make them install CubeProgrammer.

[MM..1]

Primary question is your QSPI data new require update?

Second create hex, then split it and convert hex2bin only flash part... resp leave it as hex flash part will be less as 6 MB

[Tesla DeLorean]

The standard binary representation is a single continuous blob, like driving to work, you can't fold the time space continuum and make the distance you travel any shorter.

You can break it into sections.

You can use an object file format like .DFU or .ELF which has additional meta-data describing how the content is apportioned, but that's not used/seen by the MCU.

Yeah, the tools that generate 2GB of content for a couple of MB of data are stupid. GNU/GCC does this type of embedded less well, and we've got a lot of people working on this that should know better.

Keil, by default sees multi-section objects, and breaks them into different .BIN files appropriate to the size of each, but you'd still need to manually deliver those to the right place, or program the right PROMs

For some boards you could drop content via an SDCARD, for those with ETHERNET you could slip-stream a loop of data on broadcast over the network.

You can create staged-loaders.

You can create tools to package firmware images, or generate production images. Gets real fun when you have to generate multiple PROM files with high/low byte/word combinations..

[Pavel A.]

> I'll just stick to plan B, just make them install CubeProgrammer.

If they have Windows, they can use a smaller simpler ST-LINK utility.

As for QSPI flash - Segger's J-Flash has the "universal QSPI" support that automatically detects many QSPI flash chips. All it needs to know is the exact MCU model and pins of QSPI (TL;DR) - this effectively replaces the "external loaders".

Unfortunately you cannot use it with the onboard ST-LINK, it requires a J-LINK.

> Keil, by default sees multi-section objects, and breaks them into different .BIN files

IAR has a similar utility that splits ELF to several bins.

They also produce additional executable format, "simplified ELF" IIRC - like ELF stripped down, without all the spam. Size is close to the sum of binaries.

> For some boards you could drop content via an SDCARD ...

> You can create staged-loaders ...

The whole firmware can be pushed thru the same debugger interface (SWD) that we use to program the internal flash. But software is lacking.

To program external memories, you need cumbersome "external loaders" or some kind of "semihosting" - available only with a debugger or IDE.

On the other hand, Segger provides a wonderful little utility named J-Run. It basically allows to run user's program with Segger's own semihosting and a RTT terminal, over SWD. They also provide a SDK that lets you make our own such tools, This can be terribly useful - but again, requires J-Link.

[S.Ma]

Say that your code is made of 2 bytes of value 0x11 and 0x22 in order, the first one a address 0x0 0000 and the second at 0x1 0000

The bin file will be 65537 bytes with first byte 0x11, last one 0x22 and all other will be probably 0x000

It is a binary memory dump contiguous file, like a whole screen capture.

HEX and S19 files are text file, which each line describe a memory slice with start+size address. In this case it will have 2 text lines for the 3 data bytes amd the rest will remain unchanged. It is like taking 2 small screen rectangles captures separately.

[HTD]

I figured it out from the first answer. So the Cube's bin format is the worst format ever. It may accidentally work when all data is just one contiguous block We are missing one format: bin is too dumb. Hex has too much redundancy. Elf - from what I read - also has some redundancy. And the problem to solve here is much easier than all the problems I had to solve to make my first devices built from those bricks work. I remember writing my own assembler on Atari 800XL, with only two directives "* = [address]" and "db [byte, byte, ...]". So in my asm file your example (trimmed to 16-bit addressing) would go like this: "*=0x0000 db 0x11 *=0xffff db 0x12" - 33 bytes compiled to even smaller executable that loads those bytes into exact locations. I was 10 back then and read exactly 2 books about programming. One was basic manual, the second one was a kind of datasheet for Atari. BTW, Atari DOS had an executable format that worked exactly like this - "0xff ([addr] [length] [data]...)...".

[HTD]

OMG, I missed your answer earlier, QSPI data is labelled as FlashExt by TouchGFX and I think it doesn't always require updating. Correct me if I'm wrong, but I believe it the TouchGFX uses QSPI memory to store its assets, so if the assets are not changed, I don't need to update that part of memory. So now - how can I remove the QSPI part from the HEX file? The hex file is generated by linker built in STM32CubeIDE. It's generated using the linker script that is also generated by STM32CubeIDE.

[Tesla DeLorean]

Likely spit out via OBJCOPY in this instant.

I'd kind of expect the .HEX to be relatively linear, so you should be able to find the record describing the 0x90000000 basis, it will be a shorter record, as the blocks of data span 64KB in most cases.

You should be able to cut the data with an editor/script, leaving the closing records. The patterns should be easy to match.

OBJCOPY or SRECORD should be able to narrow things down, not tools I use day-to-day.