STM32CubeMX NUCLEO-H755ZI-Q project doesn't work with M4 core

[UBöke.1]

Creating an CubeMX project with just a minumum of functionallity (M7 / M4 SysTick) can be started for the M7 but not for the M4 ???

M4 sometimes works, sometimes raises a memory error!

Greatings from Saint Égrève.

[FBL]

Hello @Uwe Böker​ 

Could you please explain how the project doesn't work! If possible, share a screenshot of the memory error so that we could help you! You may need to check the sequence of boot as well. When system initialization is finished, M7 will release M4 by means of HSEM notification and wait until M4 wakes up from stop mode. 

[UBöke.1]

Hai, Fxxx :) My name is Uwe, I'm from Germany and I work as a freelancer for INOCEL, Saint Égrève.

The code below was generated directly from the STM32CubeMX for the M4 (remarks removed).

int main(void)

{

__HAL_RCC_HSEM_CLK_ENABLE();

 HAL_HSEM_ActivateNotification(__HAL_HSEM_SEMID_TO_MASK(HSEM_ID_0));

 HAL_PWREx_ClearPendingEvent();

 HAL_PWREx_EnterSTOPMode(PWR_MAINREGULATOR_ON, PWR_STOPENTRY_WFE, PWR_D2_DOMAIN);

 __HAL_HSEM_CLEAR_FLAG(__HAL_HSEM_SEMID_TO_MASK(HSEM_ID_0));

...

If I set a breakpoint @ EnterStopMode..., and resume it afterwards, it works, but the M7 doesn't run.

If I just flash it and switch the board Off and On again, it also works for both kernels.

Within the IAR and without a breakpoint, I got what can be seen in the attachement.

Regards, YouB

[FBL]

Hi Uwe and welcome to ST Community :D

When you run the program without a breakpoint, the M4 and M7 cores may not be synchronized properly before entering STOP mode, which could cause issues when resuming normal operation.

Adding synchronization barrier in this case before entering stop mode.

__DSB();

When you switch off and on the board, it gives the system enough time to reset and synchronize the access to shared resources, which could explain why it works for both kernels.

Also, try to increase the stack size in the linker configuration.

Hope this helps!

Firas

[UBöke.1]

Hai, Firas,

I tried it with different settings (__DSB(); ...) even with a FreeRTOS project... always the same. If I put a breakpoint before entering STOP mode (M4 project), then it works for the M4. The reset works for normal projects, but not for the FreeRTOS project.

For this, the M7 runs and the M4 comes till GPIO_Init and dies...

[FBL]

Could you please share your configuration? Ioc file may would help to investigate further. Any implementation in you code would help as well to reproduce this issue.

Would you precise the stack size set in the linker configuration? Would you share the Options Bytes config?

[FBL]

Note that, CM4 program will be copied by CM7 program. So, after booting sequence of each core, you can add breakpoint and debug your code. Otherwise, a warning of stack outside the range is fired since the memory is corrupted. After that, the debug fails.

Here is an example to debug both cores. Make sure to enable multicore debugging/shared mode in STLink configuration.

Hope this helps understand the issue!

Firas

[UBöke.1]

I’ll check that during the day… thank you!

[edit: personal data removed by moderator]

[UBöke.1]

Hai,

there is no link to the dual core debug sample.

How can I upload my project ?

M4 => RED Led with 10 Hz, works if started from the debugger and a first stop at the breakpoint

M7 => GREEN led, works always

[edit: personal data removed by moderator]

[UBöke.1]

Hai, Firas,

find attached the complete project.

Dual debug doesn't work, even if the option is enabled. I'm using a NUCLEO-H755 board. I've two of them... both react in the same way.