Bugs in CubeIDE code generation for STM32WB55CG (and others)

Good! I am using the linker generated through makefile and working fine, just wanted to report the issue so that you can fix it;)

Moreover, which is the role of the *_RAM.ld linker script that is generted only fot cubeIDE? It is the first time that i see this

Thanks!

It’s a generated linker script in case you want your application to run in RAM instead of Flash. There are some use cases where you might need to execute from or test in RAM so CubeMX provides an already generated script for that. Of course we still expect the vast majority to still place their applications in Flash memory because it’s easier with things such as restarting the application, which is why it’s still the default.

Hi Remi,

I am going to change linker script for STM32WB55RGV6.

I have changed original LD file to what you have proposed and CubeIDE cant build the project anymore:

/* Entry Point */
ENTRY(Reset_Handler)
 
/* Highest address of the user mode stack */
_estack = 0x20030000;	/* end of "RAM" Ram type memory, 2019-10-01, Changed */
 
_Min_Heap_Size = 0x200;	/* required amount of heap */
_Min_Stack_Size = 0x400;	/* required amount of stack */
 
/* Memories definition, RAM 2019-10-01, Changed */
MEMORY
{
 FLASH	(rx)		:ORIGIN = 0x8000000,	LENGTH = 1024K
 RAM	(xrw)			:ORIGIN = 0x20000000,	LENGTH = 191K
 RAM_SHARED (xrw) :ORIGIN = 0x20030000, 	LENGTH = 10K
}
 
MAPPING_TABLE (NOLOAD) : { *(MAPPING_TABLE) } >RAM_SHARED
MB_MEM1 (NOLOAD) : { *(MB_MEM1) } >RAM_SHARED
MB_MEM2 : { *(MB_MEM2) } >RAM_SHARED

I got an error: STM32WB55RGVX_FLASH.ld:18: syntax error

Can you please clarify, why i have to add

"

MAPPING_TABLE (NOLOAD) : { *(MAPPING_TABLE) } >RAM_SHARED

MB_MEM1 (NOLOAD)   : { *(MB_MEM1) } >RAM_SHARED

MB_MEM2        : { *(MB_MEM2) } >RAM_SHARED 

" ?

Thanks!

The extract of the linker script I exposed ahead is from one of the BLE examples of the CubeWB FW package. The communication in between the 2 cores of the STM32WB (M4 and M0+) is done through command buffer. This buffer is placed in the MB_MEM1 section located in the RAM-SHARED region in memory.

The pragma to achieve this is in the app_ble.c file.

PLACE_IN_SECTION("MB_MEM1") ALIGN(4) static TL_CmdPacket_t BleCmdBuffer;

 Same implementation for the event end System command buffers which are placed in the MB_MEM2 section (see app_entry.c file for the pragma)

PLACE_IN_SECTION("MB_MEM2") ALIGN(4) static uint8_t EvtPool[POOL_SIZE];

PLACE_IN_SECTION("MB_MEM2") ALIGN(4) static TL_CmdPacket_t SystemCmdBuffer;

PLACE_IN_SECTION("MB_MEM2") ALIGN(4) static uint8_t SystemSpareEvtBuffer[sizeof(TL_PacketHeader_t) + TL_EVT_HDR_SIZE + 255U];

PLACE_IN_SECTION("MB_MEM2") ALIGN(4) static uint8_t BleSpareEvtBuffer[sizeof(TL_PacketHeader_t) + TL_EVT_HDR_SIZE + 255];

So the 3 lines you mentioned are not relevant if you are developing your own  inter-processor communication.

The error comes from the fact that the 3 sections MAPPING TABLE, MB_MEM1 and MB_MEM2 do not exist in your project.

The key primary error with your first linker script was the location of the _estack at 0x20004000.

​Please have a look inside the CubeWB FW package under the directory STM32Cube_FW_WB_V1.2.0\Projects\P-NUCLEO-WB55.Nucleo\Applications\BLE\.

Here you'll find a lot of BLE projects. Under each project, use the SW4STM32 files that are made to be used/converted for CubeIDE.

Definitively a bug.

Sounds some improvements have been done Thanks STM32CubeIDE V1.1.0 just released on st.com

Note that a new CubeWB FW V1.3.0 Package and a new Cube Programmer v2.2 have also been released yesterday.