Associate

Question

Trouble with the STM32CubeWL Dual Core example projects

Forum|Forum|5 years ago
January 20, 2021
16 replies
6548 views

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!

This topic has been closed for replies.

Aurelian Lazarut

Associate II

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

ST Employee

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

Associate II

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

Associate II

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.MilesAuthor

Associate

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

Associate II

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

ST Employee

Hello,

Thank you for your remarks,

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

Br,

Yoann

YBOUV.1

ST Employee

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,

WL-M0PLUS-StartUpFiles.7z

FYASA.1

Associate II

Hello,

There is a different error on my side.

I'm working on LoRaWAN_End_Node_DualCore project.

I was getting this error before apply your patch named "WL-M0PLUS-StartUpFiles"

/Applications/STM32CubeIDE.app/Contents/Eclipse/plugins/com.st.stm32cube.ide.mcu.externaltools.gnu-tools-for-stm32.9-2020-q2-update.macos64_1.5.0.202011040924/tools/bin/../lib/gcc/arm-none-eabi/9.3.1/../../../../arm-none-eabi/bin/ld: LoRaWAN_End_Node_DualCore_CM0PLUS.elf section `.text' will not fit in region `ROM'
/Applications/STM32CubeIDE.app/Contents/Eclipse/plugins/com.st.stm32cube.ide.mcu.externaltools.gnu-tools-for-stm32.9-2020-q2-update.macos64_1.5.0.202011040924/tools/bin/../lib/gcc/arm-none-eabi/9.3.1/../../../../arm-none-eabi/bin/ld: region `ROM' overflowed by 7240 bytes

After applied your patch. Im getting smilar error.

/Applications/STM32CubeIDE.app/Contents/Eclipse/plugins/com.st.stm32cube.ide.mcu.externaltools.gnu-tools-for-stm32.9-2020-q2-update.macos64_1.5.0.202011040924/tools/bin/../lib/gcc/arm-none-eabi/9.3.1/../../../../arm-none-eabi/bin/ld: LoRaWAN_End_Node_DualCore_CM0PLUS.elf section `.text' will not fit in region `ROM'
/Applications/STM32CubeIDE.app/Contents/Eclipse/plugins/com.st.stm32cube.ide.mcu.externaltools.gnu-tools-for-stm32.9-2020-q2-update.macos64_1.5.0.202011040924/tools/bin/../lib/gcc/arm-none-eabi/9.3.1/../../../../arm-none-eabi/bin/ld: region `ROM' overflowed by 8176 bytes

this patch didn't fix my problem.

What's wrong ?

Cartu38 OpenDev

Graduate II

Have try to build "Relase" build configuration ... if no overflow move back to "Debug" one and fine tune compiler optimization ...

Aurelian Lazarut

Associate II

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

mromani2

Associate

Hi,

I still have the same problem in End_Node_Dual_Core example after replacing attached files.

region `ROM' overflowed by 8296 bytes	LoRaWAN_End_Node_DualCore_CM0PLUS

Miguel

YBOUV.1

ST Employee

Hi,

you are probably trying to compile with GCC in optimization for size O0.

In this case, the resulting binary size is to big to fit in the allocated M0+ memory.

In debug build, we advise to use at least optimization -Og.

please let us know,

Best regards

mromani2

Associate

You are wright, I increased ROM size in M0+ and M4 liker files and now can download both firmware's. I still get a warning about the MAPPING_TABLE placement

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

I have read in the documentation that I can bypass the while{1} loop and the MCU will reset with the correct values but I wan't to understand the other solution. Is the scatter file the same as the linker option file (STM32WL55JCIX_FLASH.ld)?

Anyway I will try first changing the optimisation option.

Thanks for your answer.

Show more replies

Sign up

Login with SSO

Login to the community

Login with SSO

Scanning file for viruses.

This file cannot be downloaded