STMWB55: Flash write access during BLE connection

[APort]

Hello,

We are trying to write(erase) the flash during BLE connection.

If we follow the STM32Cube_FW_WB_V1.4.0/Projects/P-NUCLEO-WB55.Nucleo/Examples/FLASH/FLASH_EraseProgram

Example the BLE connection terminates immediately (timeout error code).

Apparently you have to let the CPU2 know that you are about to access the flash. The only example I found for this is:

STM32Cube_FW_WB_V1.4.0/Middlewares/ST/STM32_WPAN/ble/mesh/PAL/STM32WB/pal_nvm.c

It works when BLE is not connected.

When there is an active connection the code is stuck in dead-loop on first:

while(LL_FLASH_IsActiveFlag_OperationSuspended());

(pal_nvm.c line 226).

Once BLE device is disconnected, it passes this while.

Now... I am trying to erase a single sector, and this happens even before address is given or anything; no prior errors.

The Erase is called from main loop handler.

CPU2 firmware used is 1.4.0 (latest).

Any ideas?

Thanks in advance.

[Remi QUINTIN]

Sem2 gives the ownership of the Flash memory and Sem7 is only used at the time the write access is done to ensure M0+ is not using the Flash memory at the same time.

SEM7 is Used by CPU2 (M0+) to prevent CPU1 (M4) from writing/erasing data in Flash memory

Sem7 is used to protect the CPU2 timing versus write/erase Flash memory operation requested by CPU1. The CPU1 must get Sem7 before writing or erasing. Sem7 must be taken and released for each single write or erase operation, but not for more than 0.5 ms in addition to the write/erase timing. To comply with this requirement, the code has to be executed in the critical section. The algorithm is described in the picture below.

[APort]

Thanks Remi,

The "Release Sem3" is a typo in the diagram? Should it be Sem7?

If so when should I use the Sem2? should it surround this entire flow?

Any chance there's an example code for proper flash erase?

Thanks in advance

[Remi QUINTIN]

Indeed it is a typo . You should read SEM7.

Yes the get and release of SEM2 is surrounding this sequence using HAL_Lock() et HAL_unlock() function calls.

This figure only describes the potential issue of the timing protection for the M0+ to be able to manage the RF IP.

The Sem7 is a way for the CM0+ to allow the CM4 core to effectively write to the flash.

[APort]

1) I did try to lock everything with Sem2 - unfortunately, it did not help (not measurably at least).

while(LL_HSEM_2StepLock(HSEM, CFG_HW_FLASH_SEMID, 88)) { };

// my prev write code

LL_HSEM_ReleaseLock(HSEM, CFG_HW_FLASH_SEMID, 88);

2) "HAL_Lock() et HAL_unlock()" - did you mean HAL_FLASH_Unlock() and HAL_FLASH_Lock()? as the former are not defined.

[Remi QUINTIN]

1) Please have a look at the picture showing a more complete sequence for the flash memory access

2) Yes the functions are HAL_FLASH_Unlock() and HAL_FLASH_Lock

[APort]

Thanks for the diagram, very useful.

I found the issue we've been having - we missed the lock every 64bit write. It somewhat works now.

The lowest connection interval we manged to work with using sem7 is 70ms.

Is this is the expected value for this design?

[lukasz2]

Hello APort,

Can you share your improved FLASH access functions?

Thanks in advance

[Remi QUINTIN]

A complete example will be provided in the next CubeWB FW package V1.6.0 planned to be delivered by 20w14.

[Christophe Arnal]

​Hello,

The CPU2 does not need to access the flash on each interval but it needs to prevent the CPU1 to start flash processing to protect the BLE Timing.

As long as we are sharing the same flash, both CPUs will be stalled when either a write or erase operation is ongoing.

In order to protect our critical code responsible of the BLE timing, we are preventing any access to the flash during BLE event.

The overal picture is:

Sem2 is use to take the ownership of the Flash IP. Ony the CPU that took the semaphore can write/erase the flash.

Sem7 is used by the CPU2 to notify the CPU1 he is not allowed to start flash processing.

we have just published a new revision of the AN5289 rev3 with much more details on flash management - including the algorithm to be implemented.

In addition, we are planning to deliver in the next package v1.6.0 a example where the flash is erased/written while a BLE link is setup. It wil come with a flash driver that could be used as is.

Please note that this delivery is not yet committed but very likely to be there.

The v1.6.0 is expected in the coming weeks ( date is not yet committed)

Regards.