STM32H755 : Can both M7 and M4 access both internal flash banks in parallel?

[murali.karicheri]

Can M4 write to part of Bank 1 when M7 code is running from Bank 1? Idea is to define a

partition at the end of Bank 1 and M4 write to it while M7 reads from it. I know this

needs some tweaking of the dts to assign both Bank 1 and Bank 2 to M4 as below. IOW, as per SoC

design, can M7 code runs from a partition on Bank 1, and read data from another partition

(128 KiB) at the end of Bank1 which is also written by M4. In DTS, I plan to update DTS

to have flash0 assigned to M4 and it has a size of 2048 KiB with partitions like below. The fundamental question is is there is bus contention possible? Assume at driver level (in Bare-Metal using HAL driver and Zephyr), any common register write are guarded through semaphore.

&flash0 {
        compatible = "st,stm32-nv-flash", "soc-nv-flash";
        reg = <0x08000000 DT_SIZE_K(2048)>;
        partitions {
                compatible = "fixed-partitions";
                #address-cells = <0x1>;
                #size-cells = <0x1>;
                /* 768KiB RT image */
                image1_partition: partition@0 {
                        reg = <0x0 0xc0000>;
                        read-only;
                };
                /* 128KiB settings */
                configuration_partition: partition@c0000 {
                        reg = <0xc0000 0x20000>;
                };
                /* 896 KiB Archon image */
                image2_partition: partition@100000 {
                        reg = <0x100000 0xc0000>;
                        read-only;
                };
                /* 128KiB bootloader image */
                bootloader_partition: partition@1c0000 {
                        reg = <0x1c0000 0x20000>;
                };
        };
};

[TDK]

Think of the FLASH as a peripheral with a single interface. Both cores use the same interface (and have some mechanism for arbitration). The fundamental limitations of the flash interface/hardware still exist:

• For a given flash bank, reads are stalled while a write/erase is ongoing.

Flash programming times are in the hundreds of μs, which could be an acceptable delay. The erase time is on the order of seconds, which is likely not acceptable.

[FBL]

Hello @murali.karicheri 

The dual‑core synchronization and communication could be managed by the Inter-Processor Communication IPC or by hardware semaphore. The STM32H7 dual‑core feature three separate bus matrix. Each bus matrix is associated to a domain. I suggest you check AN5557 section 4. for some application partitioning examples.

[Heisenberg]

Hi Murali,

Did you have some success implementing the IPC? I'm currently confronted with the same issue. A getting started help would be great.

regards Maikel

[FBL]

Hello @Heisenberg 

Would you share your environment, software and hardware setup? Could you develop more your issue?

[Heisenberg]

Hello, @FBL

I have started working with the STM32h747i_DISCO board with the zephyr RTOS environment. I have read the reference manual and I now that the SRAM4 (38'000'000) section is used for inter-processor communication. To assure cache coherence the MPU has to be configured so the area is not cachable. My device-tree looks like this now:

/ {
  chosen {
    zephyr,ipc_shm = &sram4;
    zephyr,ipc = &mailbox;
  };
};

/ {
  sram_no_cache: memory@38000000 {
    //reg = <0x38000000 2048>;
    status = "okay";
    compatible = "zephyr,memory-region", "mmio-sram";
    zephyr,memory-region = "SRAM_NO_CACHE";
    zephyr,memory-attr = < DT_MEM_ARM(ATTR_MPU_RAM_NOCACHE) >;
  };
};

 I want to use openAMP for inter-processor communication. The application is however not able to mount the vring buffers for the uController. I'm not sure how to proceed from here.

My preferable option would be to use the Zephyr drivers. But it seems like I'll have to use STM cube example applications. The Issue here is, that the example modifies the linker scripts, which I don't want to temper with because they are auto-generated by zephyr. Any input is highly appreciated.

Regards Maikel

[tjaekel]

As I understand the "chip bus fabric": yes, they can access in "parallel". But the bus fabric will handle in which sequence: one master accessing MCU flash when an access is going on - will be postponed. But it should be possible that both MCUs access the same region in MCU flash (the bus fabric and arbitration on AXH/AHB bus will handle it).

It might not be very efficient (one MCU is "stalled" until the other MCU has finished). But potentially, the MCU flash has two banks and every bank can be accessed via a different paths (via the bus fabric).
Allocating memory in different banks, for different MCU cores, could speed up a bit the FW (to avoid a "concurrent access").