cancel
Showing results for 
Search instead for 
Did you mean: 

How does the STM32WB SRAM2 wireless stack boundary work?

MSatt.4
Associate III

Is it correct that the WirelessFwInfo_t.MemorySizeSram2A/B members describe the wireless stack occupied areas of SRAM2 in terms of 1k units (growing downwards)?

I am noticing there is memory being written to at 0x20031000 onwards, but that doesn't line up with what the docs say and what the wireless information says.

I only noticed this because there is our data in that space which was getting corrupted - work around is to reduce our memory usage and not go above that address, but why is this happening?

There is nothing to suggest it is my own code that is writing to those addresses... but of course it's hard to rule it out completely. A write watchpoint on that address also doesn't trigger.

I notice the memory starts getting written to after the first and subsequent HW_IPCC_MAC_802_15_4_SendCmd() are called - ie: suggests CPU2 is responsible for this.

We are using the 802.15.4 MAC wireless stack, v1.16.0.

Wireless info:


_legacyfs_online_stmicro_images_0693W00000bhmmMQAQ.png 

Memory view:


_legacyfs_online_stmicro_images_0693W00000bhmmWQAQ.png

2 REPLIES 2
MSatt.4
Associate III

Further suggestion it is CPU2...

Before enabling CPU2:


_legacyfs_online_stmicro_images_0693W00000bhnV2QAI.pngAfter enabling CPU2:


_legacyfs_online_stmicro_images_0693W00000bhnV7QAI.png

MSatt.4
Associate III

Bump...

Anyone from ST able to help? Thanks.