Memory map and register boundary addresses (for STM32H7A3)

[DShekter]

Hello,

I am interested in seeing the memory map of the H7A3. I have been able to find some information from the HAL drivers, but there is a lot missing. That table does not exist for the H7A3 in the reference manual, which is where the datasheet says to go. I am used to things like Table 6 in the H745 manual, or Figure 3 in the L4R/L4S manual.

Where can I find such a table?

Thank you

[Tesla DeLorean]

Peripheral space is described in page 130, in Rev 6

https://www.st.com/resource/en/reference_manual/dm00463927-stm32h7a37b3-and-stm32h7b0-value-line-advanced-armbased-32bit-mcus-stmicroelectronics.pdf

Pg 135 describes where the RAMs are

The FLASH, and mapping of the zero address space, are described subsequently.

Pg 151 describes flash banking

Would agree this could all be presented much better..

[DShekter]

Yes. I am aware of those tables. However, not only do I strongly agree it needs to be presented as it is in the other manuals, it also is missing key information about memory mapped areas that don't fit in those categories. Such as the OctoSPI and GFXMMU. Do you know where I can find that information that isn't in the HAL driver? I have found the macro definitions, but it takes a long time to find them.

For example, GFXMMU_VIRTUAL_BUFFERS_BASE defines the virtual buffers as starting at 0x25000000UL. This address is nowhere I can find in any manual.

Thank you.

[waclawek.jan]

Yes, the ST's documentation quality slips down. For example I've noticed that the 'H7 DS don't have the FMC pins table known from 'F4\'F7 anymore. Hey, you're supposed to click in Cube/CubeMX not reading some stinkin' datasheets and manuals, which lack information but feature modern feel'n'look.

JW

[DShekter]

I'm usually fine with that to an extent. CubeMX is a good program overall for those big interfaces. But even the Cube(s) don't tell me what the memory map is. I have to go digging and hope it's in a HAL driver.

[Amel NASRI]

Hi @Community member​ ,

Thanks @Community member​  for flagging this thread to bring it to our attention.

@Community member​  I agree with you on the following:

• missing memory map table
• missing base address of GFXMMU Virtual memory

I reported this internally and will keep you informed (this may take some time because of vacation period of some key contributors).

However, I don't understand exactly what is missing for OctoSPI and else than virtual memory for GFXMMU. In the table "Register boundary addresses", we have already the following:

Please provide some more details on this regard.

-Amel

[DShekter]

Hi, @Amel NASRI​ 

So those are the AHB peripheral addresses which are used for configuring the devices, but those have memory mapped functionality.

For example, if you look at the OCTOSPI block diagram (Fig 135, page 867) you see it has 2 ports. The AHB port listed in that table you've shown, and an AXI slave port to be a memory mapped device. I could not for the life of me find where that AXI slave port is mapped to. I ended up finding it on line 1964 of the huge hal .h file, and it maps to 0x90000000 (and OSPI2 maps to 0x7000000). the only mentions of these addresses are in the FMC's memory map, Table 133 (page 789) which states it doesn't control those regions. In fact, and maybe this is an error, in fig 107 (page 788) it lists those as FMC memory banks.

Likewise with the GFXMMU. The block diagram (fig 100, page 759) shows some address comes in from the AHB port (this is after an AXI->AHB) to enter its memory map. That diagram shows a 24 bit address. So the GFXMMU is accessed with a 32 bit address sent to the AXI->AHB (fig 2, page 107, bottom right), which strips off the MSByte, and passes it to the table as shown in figure 102 (page 761). and I'm really glad it shows the offsets into that 24-bit address space, but that doesn't help at all. I want to find out when it says 0x00_0000 in the GFXMMU's memory mapped space, what is that in the AXI address space? I could not find that. Where is that? That's on line 2295 of the huge HAL file, defines as 0x2500_0000. So presumably 0x2500_0000(axi)-> 0x00_0000(mmu). 0x250/0x2500 aren't strings in the reference manual, and other variations (2500, 0x25, etc) are not about the GFXMMU and even if one of them is, it would be one of hundreds of results. 0x25 has a result in the I2C section.

Thank you

[Amel NASRI · Accepted solution]

Hi @Community member​ ,

I would like to inform you that a new revision of RM0455 is currently avilable on the web.

Memory map table with all required details is added there.

-Amel

[DShekter]

Hi @Amel NASRI​ ,

I regret to inform you the memory map is incorrect. Table 6 lists 0x9000_0000-0x9FFF_FFFF as QUADSPI. The H7A3 does not contain a QUADSPI peripheral, but rather 2 OCTOSPI peripherals. The only mention of QUADSPI in RM0455 is this new faulty table and the DelayBlock, which at least mentions it could be an OCTOSPI. I believe 0x9000_0000 is for OCTOSPI1. Likewise, 0x7000_0000 I believe is OCTOSPI2. I am unsure if it is possible to have an FMC bank be remapped here. Figure 108 shows 0x9... and 0x7... not used by the FMC.

I again have to refer to the header file for this.

#define OCTOSPI1_BASE             (0x90000000UL) /*!< Base address of : OCTOSPI1 memories  accessible over AXI                                 */
#define OCTOSPI2_BASE             (0x70000000UL) /*!< Base address of : OCTOSPI2 memories  accessible over AXI                                 */

Thank you

[POLH]

Hi @DShekter (Community Member)​ ,

You are right there is a mistake in the table 6 of the RM0455.

I confirm OctoSPI1 mapped at 0x9000 0000 and OctoSPI2 mapped at 0x7000 0000

All the other address mappings have been checked again and they are OK.

It will be corrected in the next reference manual update planed to be published by end January.

BR

Patrick