cancel
Showing results for 
Search instead for 
Did you mean: 

Writing/Erasing internal flash during BLE connection

oguzcan
Associate

Hi all, 

We would like to perform write/erase actions in internal flash during active BLE connection for a slave/peripheral device. We intend to use BLE_RfWithFlash example. We are trying to establish sufficient conditions for a slave to perform write/erase operations.

Looking "4.7 Flash memory management" of AN5289, we see the constraints:

  • BLE connected: the connection interval must be longer than 25 ms + packet length, to
    be able to execute flash memory erase operation.
  • Data throughput use case: When data streaming packet is sent, the radio is kept active
    to send as much data as possible between two connection intervals. Therefore, the
    radio can not be in idle long enough to fit an erase operation. When the device is
    master, it can reduce the Connection Event Length parameter (with either the
    aci_gap_create_connection() or aci_gap_start_connection_update() command) to
    prevent the device filling completely the interval between two connection intervals.
    When the device is slave, it must request the master to increase the connection interval
    so that the data to be sent fit only part of the interval between two connections events.

 

Is it correct to conclude that, in theory, even with a very long connection interval, there is a chance that the connection event can span the whole interval and there won't be enough time to perform an erase and there is nothing at slave side to ensure an erase?


1 ACCEPTED SOLUTION

Accepted Solutions
STTwo-32
ST Employee

Hello @oguzcan 

You statement is valid for STM32WBx series (like STM32WB55) where a page erase can take up to 25ms (4/5ms for writing in flash of a 64 double word). As you noticed, only erase operation could be problematic in regards of BLE timing. As you proposed, either you need to enlarge connection interval to be sure to find a "time windows" or when possible, an option is to delay flash operation after disconnection (when receiving disconnection complete event). Now as you said, considering you can send multiple packets per connection interval, it may reduce “flash activity window side”.

 


@oguzcan wrote:
Is it correct to conclude that, in theory, even with a very long connection interval, there is a chance that the connection event can span the whole interval and there won't be enough time to perform an erase and there is nothing at slave side to ensure an erase?

This is “TRUE” in theory… in reality the max number of packets per connection interval may be much more limited. As an example, most of smartphones (Android/iOS) have a limit of ~6 packets per connection interval.

So, if your device is slave by adding the margin you mentioned, a connection interval of: 25ms + (max_number_fo_packet*packet_lenght) should always be fine to find a slot for Rf activity.

One more time, we are here talking about flash erase activity (up to 25ms), a flash write access is less problematic (4/5ms).

Anyway, I would like to emphasis that the document you mentioned AN5289 is valid for "only" for STM32WB series. It is not applicable for STM32WBA mentioned in this ticket details.

In case of STM32WBA55, It is true that with STM32WBA55 we still have the same constraints in regards of flash erase/write operation while RF operation ongoing like any BLE Soc. Anyway, the STM32WBA flash timings are small enough to ensure that even using minimum connection interval of 7,5ms we will be able to find a suitable timeslot for flash operation between BLE events (Max erase time is 3,4ms).

Best Regards.

STTwo-32

 

To give better visibility on the answered topics, please click on Accept as Solution on the reply which solved your issue or answered your question.

View solution in original post

2 REPLIES 2
Christian N
ST Employee

This post has been escalated to the ST Online Support Team for additional assistance. We'll contact you directly.

STTwo-32
ST Employee

Hello @oguzcan 

You statement is valid for STM32WBx series (like STM32WB55) where a page erase can take up to 25ms (4/5ms for writing in flash of a 64 double word). As you noticed, only erase operation could be problematic in regards of BLE timing. As you proposed, either you need to enlarge connection interval to be sure to find a "time windows" or when possible, an option is to delay flash operation after disconnection (when receiving disconnection complete event). Now as you said, considering you can send multiple packets per connection interval, it may reduce “flash activity window side”.

 


@oguzcan wrote:
Is it correct to conclude that, in theory, even with a very long connection interval, there is a chance that the connection event can span the whole interval and there won't be enough time to perform an erase and there is nothing at slave side to ensure an erase?

This is “TRUE” in theory… in reality the max number of packets per connection interval may be much more limited. As an example, most of smartphones (Android/iOS) have a limit of ~6 packets per connection interval.

So, if your device is slave by adding the margin you mentioned, a connection interval of: 25ms + (max_number_fo_packet*packet_lenght) should always be fine to find a slot for Rf activity.

One more time, we are here talking about flash erase activity (up to 25ms), a flash write access is less problematic (4/5ms).

Anyway, I would like to emphasis that the document you mentioned AN5289 is valid for "only" for STM32WB series. It is not applicable for STM32WBA mentioned in this ticket details.

In case of STM32WBA55, It is true that with STM32WBA55 we still have the same constraints in regards of flash erase/write operation while RF operation ongoing like any BLE Soc. Anyway, the STM32WBA flash timings are small enough to ensure that even using minimum connection interval of 7,5ms we will be able to find a suitable timeslot for flash operation between BLE events (Max erase time is 3,4ms).

Best Regards.

STTwo-32

 

To give better visibility on the answered topics, please click on Accept as Solution on the reply which solved your issue or answered your question.