Mbed-os: STM32WB55xG Flash data size configuration

[felipeLeast]

Description of defect

I was trying to enable KV Store to the 8 last sectors of my flash, and kept giving me the error of invalid flash alignment, despite the fact that my flash has sectors of 4096 bytes and I was using a multiple of that.

After some investigation I found the problem, the file flash_data.h define my flash size to 768Kbytes, but the STM32WB55 have a flash size of 1Mbyte. I don't know if there's a reason for this number, if the last 256Kbytes are reserved for something, but to me doesn't seam to make sense. Can anyone please confirm if that value is correct?

Target(s) affected by this defect ?

STM32WB55RG

Toolchain(s) (name and version) displaying this defect ?

ARM GCC 8.2.1

What version of Mbed-os are you using (tag or sha) ?

mbed-os-5.15

What version(s) of tools are you using. List all that apply (E.g. mbed-cli)

mbed-cli 1.10.0

How is this defect reproduced ?

import mbed-os-example-kvstore, change the start address to be over 0x80C0000 and see the error occur on the kvstore. Than change the FLASH_SIZE from 0xC0000 to 0x100000, and will succed.

[ciarmcom]

Internal Jira reference: https://jira.arm.com/browse/MBOTRIAGE-2526

[jeromecoutant]

Hi

FLASH is shared for the M4 core (mbed application) and the M0 core (BLE FW).

Limit is not very well documented in ST documents...

I found this:
https://github.com/STMicroelectronics/STM32CubeWB/blob/master/Projects/STM32WB_Copro_Wireless_Binaries/Release_Notes.html

=> stm32wb5x_BLE_Stack_fw.bin (M0 FW binary file) has been flashed at @ 0x080CB000

@LMESTM

[LMESTM]

I confirm: everything above @ 0x080CB000 is reserved to the cortex-M0 BLE FW usage and cannot be used by application.

[jeromecoutant]

@felipeLeast
Is information OK for you ?

[felipeLeast]

@jeromecoutant I understood why would have it, but the mbed-os does use the ble stack from ST or just ignores it and implements the ble Cordio on top of it?

@LMESTM About being reserved to cortex-M0, by changing that variable I was able to use that space for KVStore. I couldn't create a big program yet that would use all that flash space, but for KVStore it wasn't a problem at least on my test.

[LMESTM]

@LMESTM About being reserved to cortex-M0, by changing that variable I was able to use that space for KVStore. I couldn't create a big program yet that would use all that flash space, but for KVStore it wasn't a problem at least on my test.

Ok that might depend on the option bytes and level of security that has been applied to the target. So if this is not secured and you don't stat BLE, yes theoretically, you could use the whole flash. But what's the point of buying a BLE enabled target, with BLE subs-system, and not use it ? Better move to STM32L4 family ...

Our recommendation is really to consider that this part of flash is reserved to BLE and not use it for application purposes.

[felipeLeast]

@LMESTM Yes I can see your point, my doubt was regarding the cordio and the STM ble. Because, in the past I was using the NRF52, and they have the softdevice as well, but on mbed they don't use that and use only the cordio api. I thought it might be the same here. Then for that reason I might be able to use the BLE flash section.

[LMESTM]

@felipeLeast
Ok I get your point as well now.

• in mbed STM32WB relies on Cordio stack and API (above HCI) and not the STM32WPAN middleware from the ST standard CubeFW solution.
• but the BLE controller firmware running on cortex-M0 is by default the same as in cubeFW solution and it is always required. In mbed the controller will run only the below-HCI part. In cubeFW it can run also up to GATT / GAP layers ...

In any case, the use of cortex-M0 controller firmware ensures proper operation of the low latency BLE related firmware as they are not impacted by the mbed application running on cortex-M4.
Hope this helps.
Laurent

[felipeLeast]

Gotta it! Thank you!

[jeromecoutant]

Hi
Maybe we can close this point ?
Note I add some comments from this issue in the readme file in #12384

[bulislaw]

@paul-szczepanek-arm ^^

[paul-szczepanek-arm]

The application needs to be able to access the "effective" flash size. Currently MBED_FLASH_SIZE that is taken from the arm_pack_manager will have the value that reflects the whole flash - not the flash available to the user. We need a solution that doesn't remove sectors from pack manager but also allows the user to access something like MBED_USER_FLASH_SIZE.

Maybe this could be set in the process that updates the secure memory for the application running on CPU2?

[LMESTM]

The application needs to be able to access the "effective" flash size. Currently MBED_FLASH_SIZE that is taken from the arm_pack_manager will have the value that reflects the whole flash - not the flash available to the user. We need a solution that doesn't remove sectors from pack manager but also allows the user to access something like MBED_USER_FLASH_SIZE.

This is being defined here for now:
https://github.com/ARMmbed/mbed-os/blob/master/targets/TARGET_STM/TARGET_STM32WB/TARGET_STM32WB55xx/TOOLCHAIN_ARM_STD/stm32wb55xx.sct#L26

Maybe this could be set in the process that updates the secure memory for the application running on CPU2?

I don't get that one as I'm not sure what process you're referring to.
Can you detail a bit more your proposal ?

[jeromecoutant]

Yes, and also in flash api:
https://github.com/ARMmbed/mbed-os/blob/master/targets/TARGET_STM/TARGET_STM32WB/flash_api.c#L235
https://github.com/ARMmbed/mbed-os/blob/master/targets/TARGET_STM/TARGET_STM32WB/flash_data.h#L28

[ciarmcom]

@felipeLeast thank you for raising this issue.Please take a look at the following comments:

We cannot automatically identify a release based on the version of Mbed OS that you have provided.
Please provide either a single valid sha of the form #abcde12 or #3b8265d70af32261311a06e423ca33434d8d80de
or a single valid release tag of the form mbed-os-x.y.z .
E.g. 'mbed-os-5.15' has not been matched as a valid tag or sha.
NOTE: If there are fields which are not applicable then please just add 'n/a' or 'None'.This indicates to us that at least all the fields have been considered.
Please update the issue header with the missing information, the issue will not be mirroredto our internal defect tracking system or investigated until this has been fully resolved.

[bulislaw]

Thanks @jeromecoutant, @paul-szczepanek-arm does that work?

[paul-szczepanek-arm]

Works for me.

[jeromecoutant]

Works for me.

Then , could you close the issue ?
Thx