slow flash erase performance with sd_flash_page_erase()

[Clem Taylor]

In my bootloader I'm using sd_flash_page_erase() directly without pstorage.

The flash erase performance is exceedingly slow. It is taking 13.187 seconds to erase 132 pages or 99.9ms/page (does that have any significance). I'm using sd7.1.0 on a week old 51822QFAC. The datasheet claims 22.3ms worst case, is there really that much overhead in erasing with the softdevice?

While erasing the system should be fairly idle, except for the 7.5-30ms connection interval (not sure what ble_dfu.py is setting it to). The next erase is triggered directly from the system event and I have tried with both the scheduler enabled and disabled.

The data receive and flash write performance isn't horrible. Using ble_dfu.py with RCPT_NOTIF not enabled, I'm receiving 132K in 31.2s (34718bps) with never more then 100 bytes of flash writes pending. As a result, the erase time represents a significant portion of the upgrade time. The best part is this is on a board without an antenna, just a trace and a non-populated ceramic antenna (part hadn't arrived when the board was assembled). For my application, DFU performance is critical because I'm also using it to upgrade an external 2MB SPI flash, so hopefully there is more room to increase the BLE performance.

Any ideas where to look for the source of the slow erase?

EDIT: Additional info. The problem is caused by the connection interval, the performance I was seeing above was at 20ms, I can't imagine how bad it is at 7.5ms. At 90ms the erase took 3.94s, which is much more reasonable, but this is with android, it seems the python dfu/MasterEmulator ignores the connection parameter requests, I never get the response event.

The erase may be faster on android (lollipop), but the download is painful, with a 18.75ms interval and 20pkts/notif I'm only getting 7789bps, with a somewhat modifed python script at 20ms I get 46856bps.

If I ever have to upgrade my full 2MB external flash (ouch) it would take 6min with the python script, but 36min with the current performance I'm seeing with android. Ouch!

[Stefan Birnir Sverrisson]

Hi

Erasing a flash page will block the CPU. The softdevice needs the CPU during BLE radio event. So the flash erase procedure and radio event can not occur concurrently. So when you are calling any sd_* function you are requesting the softdevice to perform some operation but the softdevice will decide when it is actually performed in order not to break the BLE protocol. So if the BLE connection interval is 20ms or less, the softdevice will degrade the performance of the flash page erase command in order to maintain the BLE protocol.

I think if you are erasing flash pages while performing DFU via BLE, then the connection interval is less than 20ms as it is desirable to transfer the firmware image via DFU as quicly as possible, I would guess connection interval of 7.5ms. I am not sure how the internal scheduling is performed in the softdevice to multiplex between BLE packet transfer and flash erase opertation, but the multiplexing is very likely to cause the long flash erase time.

Update 13.1.2014 The likely reason is that flash write has lower priority than the BLE packet transfer, but after three unsucessful schedules of the flash write, the flash write will be elevated to higher priority and suppress the BLE connection event.

Update 2 13.1.2014 Yes, the specified 22.3ms flash page erase time in the PS should be correct. I would think 30ms connection interval should be enough to allow scheduling of flash page erase between BLE radio events. The nRF51822 can receive/send up to 6 packets per radio event, which will take up to 6ms, so the 30ms should be enough for the flash page erase and the radio event in all cases. If you are however using the Master Control Panel and the BLE dongle with the master emulator firmware, only one packet is sent/received per connection event, where the radio event will only take around 1ms, so in that case 25ms connection interval should be adequate to fit flash page erase between each radio event.

[Clem Taylor]

My grep-foo failed me. Many thanks, I knew you should be able to set the slave latency dynamically, but missed the how. I tried that out and it is a cleaner way to erase the flash. I still have the code to re-negotiate the connection interval, but I only do it on connection and try and convince the other side to use the fastest possible interval (7.5ms/android or 20ms/iOS).