Flashing large binary (> 1Mb) to STM32H753VIT not working

[GtH]

Hello everyone,

For over a year I've been involved in a project using the STM32H753VIT microcontroller.

The firmware has been in development for quite a while and has subsequently been growing.

Currently, the compiled binary is at the point where it is larger than 1 Mb in size. The STM32H753 has two banks of 1 Mb each, so 2 Mbytes total (as advertised).

Now, when this large binary is flashed onto the H7, it crashes immediately, resulting in a hardfault. When we reduce the program size (using optimizations for example), very thing works fine.

We found that the flash banks do not simply "overlap" with each other. You might think so though, by looking at the memory regions in the picture below, both FLASH-1 and FLASH-2 are address-wise contiguous.

At first we were looking for a way to set the flash to single-bank mode as we used to have it on the STM32F767VIT, but sadly this option does not seem to exist anymore on the H7.

The problem with using the two flash banks as one contiguous bank seems to lay in the organization of the internal blocks.In this screenshot you can see the flash memory organization. The last 128Kb + 2Kb are used by the "system memory" and the option byte sector. Meaning that effectively the two banks are non-contiguous, explaining why all of a sudden the growing binary would not fit anymore.

This was quite unsuspected, since we used the generated .ld files from CubeMX which we expected to be complete.

Now that the source is most likely found the question remains how to solve it.

There does not seem to be a way to create a single-bank setup as in the F7 so we are looking for other solutions.

Help would be very much appreciated!

[TDK]

They are contiguous. Bank 1 ends at 0x080FFFFF and bank 2 starts at 0x081000000. "System flash" in the table is at a different address, not between them.

Look more into the reasons for the hard fault in order to solve it.

[MTeun]

Thanks for pointing that out, @TDK​ . However, I'm working with the @Glen te Hofsté​  on this, I think we need to add some more information.

Our linker .LD file contains the following section:

/* Memories definition */
MEMORY
{
  DTCMRAM    (xrw)    : ORIGIN = 0x20000000,   LENGTH = 128K
  ITCMRAM    (xrw)    : ORIGIN = 0x00000000,   LENGTH = 64K
  RAM_D1     (xrw)    : ORIGIN = 0x24000000,   LENGTH = 512K
  RAM_D2     (xrw)    : ORIGIN = 0x30000000,   LENGTH = 288K
  RAM_D3     (xrw)    : ORIGIN = 0x38000000,   LENGTH = 64K
  FLASH      (rx)     : ORIGIN = 0x8000000,   LENGTH = 2048K
}

This is what I've setup in Ozone too (using in conjuncture with Seggers J-Link, adding FLASH Bank1 and 2 for good measurement):

Running this code leads to the following:

This is clearly not from a bug in our code, but a problem that rose (as this is not a problem with the F767, more about that a bit later).

Now, I change 1 thing, not in code, but in compiling: I will add O1 for code optimizations. The above is done with O0 (no optimizations at all).

Then the result is like this:

and now, when I start the code, it works perfectly fine!

Normally when developing, one uses -O0 to prevent weird optimizations in code which makes it harder to debug, and knowing that -O1 or even -O2/-O3 might introduce bugs. For us now its the other way around.

Also, if you look at the following document which states on page 5 and 6 resp:

2 Kbytes (64 Flash words) of user option bytes for user 
configuration: This area is available only in Bank 1. Unlike 
user Flash memory and System Flash memory, it is not 
mapped to any memory address and can be accessed only 
through the Flash register interface.

and

2 Kbytes (64 Flash words) of user option bytes for user 
configuration available only in Bank 1.

Even tho it says it is not memory mapped, using this, like instead of using -O1 but removing code and/or static data, even if bank1 is overlapping with the last 2 Kbytes of bank 1, it will generate a hard-fault, but in a different place!

Back to the previously mentioned F767:

Using the specifications as described in the following document, page chapter 4, page 14 specifically, we checked using the st-link utility the F767 chip configuration, which clearly showed us the F767 by DEFAULT is not using a dual bank configuration.

However, trying to find this for the H753 seems to be non-existent; hence the question if it is available to the H753 or that we then should stick with the F767 (which would be a bit unfortunate).

[TDK]

Not sure I'm going to be able to dig into it in detail. Does verification after flashing succeed?

The user option bytes are not mapped to any memory address. It is literally not possible for you to write or read to them directly. They are not located "at the end of bank 1". They are in no-where land and only accessible indirectly by use of registers and code in ROM.

You can certainly set the chip in single bank mode and try that.

[MTeun]

The user option bytes are not mapped to any memory address. It is literally not possible for you to write or read to them directly. They are not located "at the end of bank 1".

They are not available in bank 2 (as specified) and the practical experience is that when we removed some code/static data but still ended up in the upper 2k region of flash bank 1, it kept hard faulting.

I'm more interesting in the part where you say

You can certainly set the chip in single bank mode and try that.

Can you tell/explain how this is done?

Because neither @Glen te Hofsté​ or myself have found any documentation yet supporting this for the H753 (compared to the F767).

Thanks in advance!

[TDK]

I was talking about the F767. I got a bit mixed up in the reply with two chips being mentioned.

I don't think the H7 series has the single bank/dual bank option that some chips in the F7 series have.

[Andreas Bolsch]

There is no problem with programming a single 2MByte image starting at 0x08000000 (checked on H743ZI) . No hole nor overlap. Did you actually verify that your image was successfully programmed into both flash banks? I mean, not by using a 'verify' option during the programming but by really inspecting at least some bytes in the first and second bank?

[MTeun]

Yes. Another way I can show you that writing 'seems' to work, but still causing to crash is to do the following:

1. Define (static) r/o data to be put in the second bank using a mapping in the LD file and an attribute for the compiler
2. Check with ozone for those bytes if they're there
3. When starting the application -> it hardfaults.

Again, or my H753 is broken, or it is definately different from the H743.

[GtH]

Hello everyone,

Thank you for all the responses.

We found a solution to this weird problem.

As you already mentioned the H7 should be writable as a single 2MByte block and as several sources confirmed this we started looking elsewhere.

For the flashing and debugging of our code we use OpenOCD. For this we used the target file: stm32h7x.cfg

However, by default this expects a single bank H7 MCU, with one bank of 1MBytes!

There is another config file which sets the correct configuration for our H7 with the name: stm32h7x_dual_bank.cfg

This explains why our code compiled fine but did not seem to be flashed over both banks.

[Tesla DeLorean]

Thanks for updating the thread.

Tends to be a lot of buried and interrelating dependencies, so beyond the linker scripts or scatter files one also needs to double check the debugger scripts or configuration files.

It might help for tool vendors to be much more verbose about errors, or files, scripts and loaders pulled in as part of the debugger startup or flashing processes. Basically things like the root script or configuration files, and all files that they or subsequent ones "include" into the process. Or that the scripts themselves identify their inclusion, purpose, or expectations.