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?