MBMUXIF_WaitCm0MbmuxIsInitialized infinite loop

[bblouin]

Never gets past this check

void MBMUXIF_WaitCm0MbmuxIsInitialized(void)
{
 while (pMb_RefTable->SynchronizeCpusAtBoot != CPUS_BOOT_SYNC_CPU2_INIT_COMPLETED)
 {
 }
 /* USER CODE BEGIN MBMUXIF_WaitCm0MbmuxIsInitialized */
 
 /* USER CODE END MBMUXIF_WaitCm0MbmuxIsInitialized */
}

[bblouin]

How can I implement:

  /* start CM0PLUS */

 /* Note: when debugging in order to connect with the debugger CPU2 shall be start using workspace CM4 starts CM0PLUS */

 /* On the other hand is up to the developer make sure the CM0PLUS debugger is run after CM4 debugger */

[IREMI.1]

Hi,

it looks like only CM4 code is downloaded but not CM0 code.

When working on Dual core both images CM4 and CM0 should be downlaoded.

This can be done for example with cube programmer, but can be done also with the debugger.

This should be described in applications notes like AN5406-how-to-build-a-lora-application or AN5480-how-to-build-a-sigfox-application.

Personally I use IAR so I can tell you what I do with IAR.

 - compile and download CM4, ser a break point just the comment you show :

 /* start CM0PLUS */

 /* Note: when debugging in order to connect with the debugger CPU2 shall be start using workspace CM4 starts CM0PLUS */

 /* On the other hand is up to the developer make sure the CM0PLUS debugger is run after CM4 debugger */

 HAL_PWREx_ReleaseCore(PWR_CORE_CPU2);

This code releases CM0 from reset, now you can attach to CM0 with a separate instance of the IAR .

If you haven't yet downloaded any code you can also download CM0 code now.

I proced as follow: 

 - download using "download active application" 

 - system reset using CM4 debugger, restart, and reach again previous breackpoint

 - attach the CM0. which normally has initialised and it is waiting for CPUS_BOOT_SYNC_ALLOW_CPU2_TO_START in order to go further

[Zyuan.2]

the code were downloaded with cube programmer , but the CM0 can not be Initialized

[IREMI.1]

Hi Zyuan, 

I don't reproduce the issue (using release 1.1.0 and the nucleo board with WL55JCIx device).

Do you use same versions? 

In order to help you we should try to debug.

To debug you should change the Cmx/Core/Inc/sys_conf.h

 #define DEBUGGER_ENABLED      0 -> 1

 #define LOW_POWER_DISABLE      0 -> 1

for both cores (CM0PLUS and CM4) then recompile and download.

Attach the CM0PLUS debugger, see where the CM0 is stuck and let me know.

[IREMI.1]

Actually is also possible that Cm0PLUS has started but there is a missmatch in the address of

 pMb_RefTable->SynchronizeCpusAtBoot

between CM0 and CM4.

Normally this should not happen because CM4 gets the pMb_RefTable from the linker file

and compare it with the IPCCDBA option byte. In case of diff it rewrites the IPCCDBA and reboots.

CM0 gets this value directly from IPCCDBA option byte.

In our examples the CM4 linker files place the pMb_RefTable table in 

 define symbol __ICFEDIT_region_RAM2_SHARED_start__ = 0x20008000;

The IPCCDBA should be set to 0x800 : (0x20008000-0x20000000)>>4

This is something you could check even before start debugging ... 

If there is a mismatch means there is a problem in the above procedure,

like maybe your device is protected from option byte programming.

[fr1337ddy]

Hi, I successfully programmed the NUCLEO-WL55JC1 multiple times until I tried the FUOTA Dual Core demo like described in this video: Getting started with LoRaWAN FUOTA on STM32WL end device 

Since then, I had a lot of issues with reprogramming. I finally managed to unlock the MCU using the STM32CubeProgrammer.

Now, I can reprogram the device with the LoRaWAN End Node Dual Core project (STM32Cube_FW_WL_V1.3.0), but I get the following terminal output:

There is a difference between the MAPPING_TABLE placement in memory: 0x20007000
and the address calculated according to the IPCCDBA option byte: 0x20008000
IPCCDBA is automatically updated
System restarting...

Please check the CM4\MbMux\mbmuxif_sys.c for more info

 If I connect with STM32CubeProgrammer and read out the option bytes I get this:

So the option bytes couldn't be updated by the application.

 

If I try to do it with the STM32CubeProgrammer tool, I also get an error:

Whereas RDP level is 0 and ESE is unchecked:

 

If I use the LoRaWAN AT Slave Dual core application I get stuck during:

If I try to debug CM0+ in parallel I get an error:

 

[fr1337ddy]

I was able to fix the problem by reading out the option bytes from a new board and write the exact same configuration to my board which had problems...