STM32H7 Dual Core, GPIO is not set after power reset

[Floki.1]

Hello,

I am experimenting on the STM32H45 Discovery Board (Dual Core) to use some GPIOs from different Core-Context.

I initialized few Pins only for the CM7 and few dedicated pins only for the CM4. When I perform a debug session, all the mentioned pins are set to HIGH . I went trhough the internal registers and measured the values on the pins (3,3V). Everything seems to be ok.

But when I do a power reset (USB cable off and on) and I measure again, I see that all the output pins wich are controlled by the CM4 are LOW. First I thought it is somehow connected to the synchronization process with the hardware semaphores (generated by MxCube), but I removed those parts in order to be sure I am not missing anyhting. The Power-Down call of the Domain2 on the CM4 at the beginning is commented out. But this doesn't solve the problem after a hardware reset

Why does this even happen? I mean the H7 architecture allows you to access most of the periphericals by CM4 and CM7. But this one seems to be strange.

Is there something I need to take into account when performing a debug session and then performing a power reset? I have seen that the HAL GPIO provides a Locking mechanism for the GPIOS, but I am not using such a function call at all.

Do I need to take smth into account when the same GPIO Port Bank is initialized twice by CM4 and CM7 because different pins are used on the same PORT? In the end , you just enable the corresponding clock of the bank. Does it harm when I initialize the Clock of a specific GPIO Port Bank several times although it was already done before ? Do I mess up the H7 here ? I even tried to initialize the PORT-CLK globally only once from CM7 context, and then letting the CM4 just to initlaize the specific Pin as a output. During debugging, this also runs smooth, but after a power cycle, the GPIOs contolled by the CM4 are not set anymore. Is something getting overwritten?

For me it is hard to understand that such a behaviour is not occuring during a ST-Link Debugg-Session, but after a simple power reset, nothing is set properly.

What is wrong with my current approach ?

[TDK]

Is BOOT_CM4 high and booting to the appropriate flash address? Debug sessions force the start address whereas power on reset will boot to what is specified per option bytes and boot pins.

Enabling the clock multiple times will not cause issues.

If you're messing with the same register on both processors, there is a small chance of overwriting what the other one does due to how read-modify-write works. Use hardware semaphores or similar to avoid this.

[Floki.1]

Hello TDK,

yes BOOT_CM4 and BOOT_CM7 are set to high in the option bytes. According to the documentation, both cores start at the same time. I used STM32Programmer to check that. I also performed a "mass erase" with disabling/enabling the Flash sectors. The starting addresses for both cores are the one defined in the linker script and also in the CubeProgrammer, they are the same. Hardware semaphores are theoretically not useful because the the pins used from both cores are dedicated only to the specific cores. When I remove the GPIOs on the CM7 which seems to run during debug and after a power reset, the CM4 still doesn't set the Output high.

I tried to measure again and sometimes I see 0,5 V on the output pins of CM4 instead of 3,3V ? Could it be something with the speed confiuguration of the GPIOs? I also see in the HAL lib that you first set the corresponding Pin to a voltage level (High/Low) and then continue with the further HAL_Init (e.g. Pinnumber, mode type, speed, etc.). I would expect it the other way around (first init, then set the output explicitly). For the Read-modifiy-write issue, ST provides those BSSR aliases. Wouldn't this eleminate this problem ?

[ACand.3]

Hi there, were you able to resolve this problem?
my cm4 works immediately after flashing, but stops after physically pressing reset button or power cycle