STM32H743VG - gap in FLASH bank adresses

[TGeof.2]

Hi,

Context:

I've hit a roadblock in using the stm32h743VG.

According the reference manual, this is the FLASH memory mapping:

 

I'd like to focus your attention on the address gap between Bank1 & Bank2.

To alleviate this, I've first done the following:

MEMORY
  {
-   FLASH (rx)     : ORIGIN = 0x08000000, LENGTH = 1024K
+   FLASH_1 (rx)   : ORIGIN = 0x08000000, LENGTH = 512K
+   FLASH_2 (rx)   : ORIGIN = 0x08100000, LENGTH = 512K

This prevents corruption, as the linker initially tried to store functions in the address gap.

But this is cumbersome, as I need to use more than 512K for my `.text` output section.

Question:

Is there a way to define the FLASH region like this:

(EDIT: fixed 128k to 512k)

MEMORY
{
  FLASH (rx) : ORIGIN = 0x08000000, LENGTH = 1024K + 512K 
/* Add 512K, which is the size of the gap between banks */

And prevent the linker to use the addresses between 0x08080000 and 0x0809FFFF ?

Alternative question:

Is there a syntax that would allow me to take all `*(.text)` and `*(.text*)` input sections up until they don't fit in FLASH_1, fit that into an output section named `.text_1`, then taking the remaining `*(.text*)` input sections and fit them into `.text_2` which would go into `FLASH_2` ?

[Pavel A.]

You can define some dummy section at absolute address that covers the gap.

 By the way the gap is 512K (4 sectors), not 128K

[TGeof.2]

I need to use more than 512K for my `.text` output section.

This solution would still prevent me from doing so, since the .text section could not be contiguously spanning more than 512 K.

And the gap is 128K by my calculations?

[Andreas Bolsch]

No, it's indeed 512K, just take half of the difference of the 2M vs. 1M variants.

I'm afraid there is no simple solution and in some cases no solution at all if you have some large objects (e.g. tables of constants), the keyword is "memory fragmentation". But let's assume such case is not present in your case.

The GNU linker (and probably other as well) allows mapping of input sections from specific *object files* to output sections. So you can map .text e.g. from files a.o b.o c.o to FLASH1 and from d.o e.o f.o to FLASH2. But it's a tedious job to adjust this manually. And as the object files grow during development, you may have to split files and rearrange things.

AFAIK the 1M variant is the same chip as the 2M one, just only half of the flash tested. So if you don't do fancy things where you do need the two bank layout, you might simply use the full 1M bank 1 during early development and do the splitting and shuffling as the very last step prior to production.

[TGeof.2]

> No, it's indeed 512K,

My mistake, for some reason, I wanted to read hex addresses in decimal...

> But it's a tedious job

Precisely why I was wondering if I was missing some clever trick

[Tesla DeLorean]

>>But this is cumbersome, as I need to use more than 512K for my `.text` output section.

Yes, but until someone makes a multi-pass linker that can fill non-linear sections, you're going to have to do it manually.

You should be able to direct objects, subroutines, or sections specifically into regions, or create some script to perform some kind of floor-planning / working-set auto-magically. That tends to be what programmers do out of necessity when doing things manually becomes cumbersome or tedious..

As Andreas mentioned the parts likely have 2MB on-die, and only a subset is tested effectively.

On other STM32 platforms the banks can be placed side-by-side by option bytes so the flash lines appear 128-bit wide, vs 64-bit. In that case you'd get a single 1MB linear blob, but without the ability to erase/write the inactive bank.