STM32WB55: What is a "normal" delay on flash erase during advertisement

[OliM]

I know that flash erase during BLE activity is an issue with that controller and a lot of notification/semaphore stuff needs to be build around it. But measuring my implementation including the later today, it looks a lot more horrible than I imagined. 
If I have BLE Advertisement (no connection open!) on with Advertising_Interval_Min = 1800 Advertising_Interval_Max = 4000, deleting one block of flash takes nearly 1 second (~815ms). If I stop Advertisement afterwards, it remains the same. Only if I disable the stack completely, or did not yet start the first advertisement, I get back to the 25ms ballpark from the HW itself.
Is this really the delay I will now have to find a way to work around, or should I have a look at my flash erase routine again.

[FilipKremen]

Hello,

did you try the BLE_RfWithFlash example from WB package?

Can you please try it?

Best regards,

Filip Kremen

[OliM]

I have now taken a deeper look at the example mentioned: 
In the default setup with fast advertisement, set to work on 1 block only, it seems to work ok (~100ms until an erase is really done). But once I switch it to LP advertisement (replace the calls to Adv_Request(APP_BLE_FAST_ADV); with Adv_Request(APP_BLE_LP_ADV) , I get even worse erase times than on my own implementation (1160ms).
To me that sounds like a bug in the BLE stack, which is probably not taking action on the SHCI_C2_FLASH_EraseActivity(ERASE_ACTIVITY_ON); erase request until it has something to do via radio.

EDIT: This behavior also reproduces in my own setup. If I pump up the advertisement rate, or if I am connected, the flash erase becomes much faster.

[OliM]

Rereading AN5289, it sounds like this matches the programmed behavior
"When CPU1 sends the system
command SHCI_C2_FLASH_EraseActivity(ERASE_ACTIVITY_ON), CPU2 immediately
takes Sem7 until the next radio event, preventing any flash erase or write operations during
this period."
Which is catastrophic (and useless, why does CPU2 care about the flash while it sleeps?) during low power advertisement, because it can block flash activity for multiple seconds. So how to continue from there? Just NOT warn CPU2 if it is not connected? Or keep it in the "warned" state indefinitely?

 

EDIT: I did some measurements and it seems the "ready for flash erase" mode in CPU2 costs an additional 15µA (which is roughly 2 times the normal value) using my advertisement settings and a wooping 1800µA (on top of ~250µA) in connected mode compared to not having set SHCI_C2_FLASH_EraseActivity(ERASE_ACTIVITY_ON).
Since my biggest issue is during advertisement, it looks like I should try to switch it on as early as possible when I get my other data connections, but toggle it only on demand during BLE connection. Or someone has an idea how I can somehow trigger a "next radio event" during advertisement?

[_Joe_]

Hi,

First, what is described here is not a bug, but the expected behavior.

Since both CPUs share the same flash memory, any ongoing write or erase operation will stall both CPUs.
Because the RF scheduling is invisible to CPU1, CPU2 must take Sem7 to prevent flash erase or write operations from interfering with radio events.

The exact behavior is that when the command SHCI_C2_FLASH_EraseActivity(ERASE_ACTIVITY_ON) is issued, flash access is blocked until the next radio event occurs.
However, after this initial blocking step, you can erase as many sectors as needed during subsequent advertising events without additional penalties.

 

If, depending on your ADV/Conn interval and use case, you really need to bypass this first "unused" interval, it is possible to bypass this safety mechanism.
However, you must absolutely ensure that no conflicts occur between flash operations and RF activity.
If you can guarantee this, you may consider skipping the use of SHCI_C2_FLASH_EraseActivity commands in your application.

BR, Joé

[OliM]

I do understand that having hardware semaphores for the shared flash access makes sense, and I did later understand the current behavior of: 

---

@_Joe_ wrote:

The exact behavior is that when the command SHCI_C2_FLASH_EraseActivity(ERASE_ACTIVITY_ON) is issued, flash access is blocked until the next radio event occurs.
However, after this initial blocking step, you can erase as many sectors as needed during subsequent advertising events without additional penalties.

---

But without access to the radio code it feels unnecessary to have that "unused" interval. It's just how it is coded right now in the CPU2 code, but not how it needs to be from a hardware point of view.
---------------------------

---

@_Joe_ wrote:

If, depending on your ADV/Conn interval and use case, you really need to bypass this first "unused" interval, it is possible to bypass this safety mechanism.
However, you must absolutely ensure that no conflicts occur between flash operations and RF activity.
If you can guarantee this, you may consider skipping the use of SHCI_C2_FLASH_EraseActivity commands in your application.

---

My expectation is that there will still be no parallel access in that case because of the semaphore handling in addition to the SHCI message, but the radio timing can be delayed if CPU2 needs to wait too long for the semaphore. Is this correct?
Of course I can not "guarantee" a thing about the CPU2 code because it is closed source ;)