2021-01-20 02:09 PM
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!
2021-05-09 09:13 AM
It's possible to debug if "Release" but you may face weird behavior from time to time doing stepping. "Release" or "Debug" variation is only compiler optimization. If compiler optimizes some piece of code you may get no chance to break at a given line or to step to because optimized.
If moving from "Debug" to "Release" is leading to build success menas your project is ok already what's good. Then back to "Debug" up to you to select proper optimization allwing you best tradeof (memory footprint / debug experience). Have a try to set -Og ...
2021-05-09 10:15 AM
This approach solved my compile problem. Thank you for your help
2021-07-12 08:11 AM
After changing OB to 0x800, they still don't match. It's looking for 0xe4.
2023-03-05 09:08 AM
Hi,
For information i am on sdk STM32Cube_FW_WL_V1.3.0 and this bug still exist.
Solved by the patch.