STM32WB SRAM2A what is the size that can be used without interfering with BLE ?

[lizerd]

I really need to use the SRAM2A that can hold data while in standby mode.

But I have a hard time finding how much of the SRAM2A that I can use without meddling with BLE ?

I found (STM32WB software architecture AN5289) and the mention about SBRSA

 

But nothing more about the SBRSA address .

Any one knows ?

And also the correct way to modify the linker script to expand on the SRAM2 ?

[Remi QUINTIN]

SBRSA (Secure backup RAM start address) is an option byte only accessed by the CPU2 core. It defines the limit in between the sharable part of the SRAM2a between both cores and the part secured for CPU2 usage only. This depends on the stack used. Its value is set at the end of the FW installation. It if no use for users as they won’t be able to modify its value.

Moreover, it is hard to detail the exact the sharable part. The beginning of the SRAM2a memory is used for the device info, the buffer tables, and the various system elements to ensure a proper communication in between the 2 cores. The size may not vary that much bit it varies. So it is hard to give any accurate recommendation to define a dedicated user area in SRAM2a.

[jro]

If you look at section 4.10 of AN5289 (rev 5, if that's important...), it documents the SHCI_GetWirelessFwInfo() API call which gives information on the memory consumption of the BLE stack in use: presumably it'll vary with stack type (BLE full or light ) and version.

I ported an application from WB50 to WB15, and after a bit of fiddling about ended up with the following .icf file (IAR EWARM):

/*###ICF### Section handled by ICF editor, don't touch! ****/
/*-Editor annotation file-*/
/* IcfEditorFile="$TOOLKIT_DIR$\config\ide\IcfEditor\cortex_v1_0.xml" */
/*-Specials-*/
define symbol __ICFEDIT_intvec_start__ = 0x08000000;
/*-Memory Regions-*/
/***** FLASH Part dedicated to M4 *****/
define symbol __ICFEDIT_region_ROM_start__ = 0x08000000;
define symbol __ICFEDIT_region_ROM_end__   = 0x0801B7FF;
define symbol __ICFEDIT_region_RAM_start__ = 0x20000004;
define symbol __ICFEDIT_region_RAM_end__   = 0x20002FFF;
/*-Sizes-*/
define symbol __ICFEDIT_size_cstack__ = 0x400;
define symbol __ICFEDIT_size_heap__   = 0x400;
/**** End of ICF editor section. ###ICF###*/
 
define symbol __ICFEDIT_region_RAM_SHARED_start__ = 0x20030000;
define symbol __ICFEDIT_region_RAM_SHARED_end__   = 0x200327FF;
 
define memory mem with size = 4G;
define region ROM_region        = mem:[from __ICFEDIT_region_ROM_start__   to __ICFEDIT_region_ROM_end__];
define region RAM_region        = mem:[from __ICFEDIT_region_RAM_start__   to __ICFEDIT_region_RAM_end__];
define region RAM_SHARED_region = mem:[from __ICFEDIT_region_RAM_SHARED_start__   to __ICFEDIT_region_RAM_SHARED_end__];
define region Total_RAM_region  = RAM_region | RAM_SHARED_region ;
 
define block CSTACK    with alignment = 8, size = __ICFEDIT_size_cstack__   { };
define block HEAP      with alignment = 8, size = __ICFEDIT_size_heap__     { };
 
/* MB_MEM1 and MB_MEM2 are sections reserved to mailbox communication. It is placed in the shared memory */
initialize by copy { readwrite };
do not initialize  { section .noinit,
                     section MAPPING_TABLE,
                     section MB_MEM1 };
 
place at address mem:__ICFEDIT_intvec_start__ { readonly section .intvec };
 
place in ROM_region        { readonly };
place in RAM_SHARED_region { first section MAPPING_TABLE};
place in RAM_SHARED_region { section MB_MEM1};
place in RAM_SHARED_region { section MB_MEM2};
place in RAM_SHARED_region { block CSTACK, block HEAP };
place in Total_RAM_region  { readwrite };

So for the stack version in use (sorry, can't remember which it was), I had all 12k of SRAM1 available, 10k of the 32k SRAM2a, and 0k of the SRAM2b. As you can see, I had to use a few "place in X region" lines to shoehorn the application into the rather small space available. For some reason the BLE stack needed 26k of my total 48k, and still only allowed me 500 bytes of attribute value space...

[Christophe Arnal]

Hello,

Basically, you can use any unsecure SRAM2A area that is currently not used in your application.

Buffers required by BLE are either in SRAM2A in the secure area that anyway you cannot access or are provided by CPU1 to implement the MailBox ( these buffer are part of you map file).

So any unused unsecure SRAM2A can be used safely by the application for any BLE operation.

Note: It could be safe to let 1K margin of SRAM2A just below the secure SRAM2A in case we need more secure SRAM2A in some feature release. However, this is extremely unlikely has this has never been the case since mass market launch in 2019 ( we never increased SRAM2A secure requirement).

Regards.