Flash storage usage with multiprotocol BLE + Thread

[Krzysztof Cieniawski]

Hi!

I am currently developing product containing Thread mesh and BLE peripheral service. I am using Thread SDK v2 in my software. My application has to support writing to MCU flash. I am trying to do it with working radio. Unfortunately my application stops on first command, which is flash erase command. Flash storage module says it is busy, forever. My question is if nrf_fstorage module works with thread and BLE or am I supposed to turn off radio or one of protocols. I am also using scheduler in my application,. what may be important.

[tesc]

Hi,

Fstorage works with BLE and Thread, but flash access must go through the SoftDevice API and is subject to SoftDevice scheduling. If no appropriate timeslot can be found for the flash operation it may time out. Flash erase is the most time consuming flash operation and so it is the operation most likely not to get through.

The key for flash operations to succeed is to make sure other radio activities leaves gaps long enough for successful scheduling of flash operations. See also the S140 SoftDevice Specification sections on Flash API timing and on SoftDevice timing-activities and priorities. (The 802.15.4 radio driver uses "Radio Timeslot with high priority".)

Regards,
Terje

[Krzysztof Cieniawski]

Hi Terje,

first of all thank you for very quick response. Since Monday I have tried to reduce radio usage or to change fstorage configuration. Unfortunately it hasn't helped. When I removed scheduler and change NRF_SDH_DISPATCH_MODEL value to interrupt (value 0) from scheduler (value 1), it helped.  I have also enabled NRFX_PRS because it is enabled in fstorage example. Now in my application work both BLE and Thread without problem with fstorage. Also scheduler work correctly with NRF_SDH_DISPATCH_MODEL = 1.

I have one more question. Does app_scheduler work with fstorage when NRF_SDH_DISPATCH_MODEL = 1? Changing it to 0 removed all my problems.

[tesc]

Hi,

As far as I know the dispatch model used by the SoftDevice Handler (SDH) should not affect the functionality of other modules, although there might be a caveat there since fstorage uses the SoftDevice for flash access. I find it just as likely that enabling Periperal Resource Sharing (PRS) may have solved a problem.

I do not quite understand what configurations you have tried that work and what configurations you have tried that does not. Did using the scheduler work flawlessly, also for SDH, after having enabled NRFX_PRS?

Regards,
Terje

[Krzysztof Cieniawski]

Try to answer for your question about configuration I must say that I do not remember exactly which values I set but I can write which parameters ware change and why:

- in fstorage module I was changing value of NRF_FSTORAGE_SD_MAX_WRITE_SIZE. I tried to reduce this value to increase chance of successful operation

- in BLE peripheral I was trying to reduce adv interval, connection intervals and connection sup timeout, also to increase possibility of success by reducing radio usage.

Configuration changes I made that ended in working devices are:
MIN_CONN_INTERVAL                   MSEC_TO_UNITS (60, UNIT_1_25_MS)
MAX_CONN_INTERVAL                   MSEC_TO_UNITS (100, UNIT_1_25_MS)
CONN_SUP_TIMEOUT                    MSEC_TO_UNITS (500, UNIT_10_MS)
FIRST_CONN_PARAMS_UPDATE_DELAY      APP_TIMER_TICKS (5000)
NEXT_CONN_PARAMS_UPDATE_DELAY       APP_TIMER_TICKS (30000)
APP_ADV_INTERVAL                MSEC_TO_UNITS (40, UNIT_0_625_MS)
NRF_FSTORAGE_SD_MAX_WRITE_SIZE 4096
NRFX_PRS_ENABLED 1
NRFX_PRS_BOX_4_ENABLED 1
NRF_SDH_DISPATCH_MODEL 0thread configuration:
role = RX_OFF_WHEN_IDLE
autocommissioning = true
poll_period = 10000

I have not tested scheduler precisely because currently I am implementing functionality connected with flash storage however till today it has not failed. It is rather early stage of development but I am using some already made modules and soon scheduler will be tested. If I find any problem or better solution I will post it here.

[tesc]

Hi,

I see.

You should rather try to increase the connection interval. That way there will be more room in-between events.

Actually I found some more information on when flash write/erase can be expected to succeed given various examples of BLE activity, in the Flash memory API section of the SoftDevice Specification. See "Table 1. Behavior with Bluetooth Low Energy traffic and concurrent flash write/erase" on that page.

Regards,
Terje