My own bootloader for STM32H750, is this possible?

[andre239955_st]

Hi,

We have devellopped our own bootloader for the different families of STM32. This is based in one sector of the flash while it is able to reprogram the other sectors. Now I am working with a STM32H750 but this one has only 1 sector... I might already know the answer but I would like confirmation, can I use my own booloader here?

If not, what means do I have for reprogramming a device with its read protection activated?

Thanks,

André

[Uwe Bonnes]

Why do you need your own bootloader? Have some switch in your start up code that evokes the builtin bootloader on some settable condition.

[andre239955_st]

I knew this question would follow :)

The answer is that we have to activate the read protection. When you want to reprogram it with Dfuse or Jtag you have to remove the protection first. This can take up to 30 seconds depending on the device.

We produce over 1 milion devices a year so every second counts. This is why we have our own bootloader INSIDE the read protected flash. This bootloader is allowed to rewrite the flash without removing the protection. This only works of course if the bootloader is in a different sector than the application.

[Uwe Bonnes]

What about storing (encrytped) firmware in external (QSPI) Flash. I think STM32K750 + QSPI is still way cheaper than STM32H43. But encrypted flash opens another attack vector...

[andre239955_st]

Correct but QSPI x 1 million = still a huge amount of money...

I'm digging further, there is a system memory bank 2 which could be a solution. I have requested x-cube-sbsfu which could (hopefully) do the job in the right way.

Lucky I am still in an evaluation phase, I can still switch to another micro/brand.

[Tesla DeLorean]

Probably should check how much memory is actually on the die, most likely has the same 2MB as the H743ZI

The H750 is designed as a low cost entry level device, if you need more functionality you should use the H753 or expand memory via QSPI.

Honestly I think the approach here is the dumbest possible, ST really should provide a larger flash options or just rationalize the pricing structures better. The irony here is the F750 (the F7 valueline equivalent) has 64KB of FLASH, but the demo code it ships with consumes close of 192KB, so a bunch of the "dark" FLASH on die.

[Uwe Bonnes]

STM32H750 and STM32H743 have the same DEV_ID in MCUDBG. So they have the same die. Flash above the flash announced in Flash size register may have been invalidated by some fuse and is probably untested. If even ST ships STM32H750 with a demo bigger than the announced flash, probably no fuse invalidates the flash...

[Alex R]

You may be able to run your bootloader from RAM while upgrading the Flash Sector.

[Tesla DeLorean]

Well definitely untested. The flash will consume a lot of expensive tester time, so by dispensing with it they can actually get some economy of scale, perhaps 10x to 16x the throughput on the equipment.

[andre239955_st]

@Alex R: if I don't find another solution then I'll have to do that. Our bootloader (which takes itself care of the erase) never erases itself so it stays in flash. Therefore it also can handle power loss during the upgrade. With a bootloader in RAM that works not as good...