Trouble with the STM32CubeWL Dual Core example projects

[Stephen.Miles]

I've just gotten a Nucleo-WL55JC1 and am having a bit of trouble getting the dual core example applications working out of the box. The single core AT_Slave and End_Node examples do however compile, program and run on the M4 core with no issue. We are able to set up the node and get it joined to our lrwan network.

I am using the CubeIDE toolchain. This is my first go at working with a dual core STM32 so it's quite possible I'm just missing something fundamental.

The first issue seems to be in the program size for the M0+. With the default project configuration, the binary for this core ends up taking overflowing its 128k allocated ROM by 7360bytes. I am able to correct for this by either turning on any degree of compiler optimization, or by adjusting the ROM regions defined in the linker script for the M4 and M0+ cores to give the M0+ more space.

After implementing either of the above changes to allow the build to complete, I set up a debug configuration flash both images and attach the debugger in the M4's context.

The binaries both seem to download successfully, however running the program returns the following error over the device's UART:

 WARNING: There is a difference between the MAPPING_TABLE placement in memory: 0x20008000

 and the address calculated according to the IPCCDBA option byte: 0x2003FFF0

 The execution enters now in a while(1){}

 please check the CM4\MbMux\mbmuxif_sys.c or update the scatter file

Going through UM2643 and AN5406 I haven't come across anything obvious I might have missed - any suggestions or insights would be welcome.

Thanks!

[Aurelian Lazarut]

I subscribe to the post above - same problem. We are seriously wondering if this MCU is ready to be used in a product.

I manage to get further after erasing the device - I programed both CM0 & CM4 and the software started. Pressing the push button triggered the Sigfox transmission (visible on the spectrum analyzer) - However after the board is powered off the board is not starting anymore (no messages in the st-link terminal) - no response after pressing the reset. (completely dead)

Starting the whole process again - device erase / programming the CM0/CM4 make the board alive as long as you don't disconnect the power again.

Aurelian

[YBOUV.1]

Hello,

The option byte IPCCDBA probably does not match MAPPING_TABLE address in the linker file at STM32CubeIDE\CM4\STM32WL55JCIX_FLASH.ld.

• MAPPING_TABLE is mapped at RAM_SHARED (@0x20008000). Mapping table is used to exchange data between the cores.
• To see IPCCDBA, connect with cube programmer, open tab 'OB', section 'User Configuration', scrolling down to bottom you will find it.

following rule shall apply IPCCDBA = (MAPPING_TABLE>>4)

please try to program manually option byte IPCCDBA to 0x800. The board will restart to reload the new OB value.

please let us know,

[Aurelian Lazarut]

An out of the box board (brand new) has the IPCCDBA = 0x3FFF so definitely need to be manually programmed to 0x800.

I programmed IPCCDBA to 0x800 (using stlink3) and then the CM0 & CM4 from the example and the boards starts correctly, responds to reset and to the push button.

The moment you unplug the board (remove the usb cable) and plug again is not starting anymore. (unless I re-flash the CM0 & CM4)

I have two dev boards same behavior on both.

Aurelian

[Aurelian Lazarut]

Trying to debug this in STMCubeIDE - debugger is nor working due to LPM modes probably so I disabled the LPM mode

but it seems to me a start-up issue is getting stuck here.

void MBMUXIF_WaitCm0MbmuxIsInitialised(void)
{
  while (pMb_RefTable->SynchronizeCpusAtBoot != CPUS_BOOT_SYNC_CPU2_INIT_COMPLETED)
  {
  }

(pMb_RefTable->SynchronizeCpusAtBoot = 0x5555

and

CPUS_BOOT_SYNC_CPU2_INIT_COMPLETED = 0xAAAA

which looks like the two CPU can't achieve SYNC

I'm not going to dig further, it seems that I'm doing someone else's job (for free) 

Good luck with your product.

Aurelian

[Stephen.Miles]

So I had tried doing that (Setting the line 128 #if to 0 in the MBMUXIF_SystemInit() function in CM4/mbmbuxif_sys.c), however afterwards I'd found that the debugger was unable to attach to the CM0+ context, and the CM4 was able to attach but the core appeared halted at HAL_Init() in main() and would not resume through debugger commands. Additionally power cycling the device did not yield any output over the device serial port so I'd assumed it wasn't just a debugger related issue. Finally the only way I was able to get the programmer to re-attach in order to flash a new program, both in CubeProgrammer and CubeIDE, was to have the NRST button held down on the nucleo when I tried to connect the ST-LINK.

However, I hadn't thought to try disabling LPM until reading Aurelian's post, and upon doing so (by going into sys_conf.h on both M0+ and M4 projects and changing LOW_POWER_DISABLE to 1) I was immediately able to get the debugger connected on both core's contexts, and the AT interface over UART seems to work without issue. Our lrwan gateway isn't up at the moment but I should be able to try adding it to the network and sending some data sometime in the next day or two.

I am having the same issue Aurelian is having: when power is removed I have to reflash both cores to get the system to run. Only removing power seems to cause this issue - a reboot through NRST after flashing does not yield this behavior.

[Aurelian Lazarut]

I think the whole point of buying a dev board and using a software example is lost here. Instead of helping the customers to get their application up and running in a matters of hours, this is becoming a collection of frustrating experiments and workarounds. Nor sure what's the point to release those examples when not working out of the box. I have a very low pain threshold, if I cant get it working in a day of digging then it's not for new product yet, I got burnt to many times.

Aurelian

[YBOUV.1]

Hello,

Thank you for your remarks,

We will try to reproduce the issue and let you know,

Br,

Yoann

[YBOUV.1]

Hello,

we have reproduced the issue and found a solution.

The specific RAM memory, where Feat_Info_Table is located, is not initialized by the linker/starter file on the Cortex M0+ side. (Feat_Info_Table is located in \CM0PLUS\MbMux\features_info.c )

To solve the issue the following files must be replaced (by the ones in the zip attached):

• STM32CubeIDE\CM0PLUS\STM32WL55JCIX_FLASH.ld and
• STM32CubeIDE\CM0PLUS\Application\User\Startup\startup_stm32wl55jcix.s

Please let us know,

[Aurelian Lazarut]

Hi Yoann,

Your fix is working fine, please refresh the Sigfox example availble on the ST.com to avoid other complaints.

Thanks for the quick solution,

Aurelian