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]

This seems to be what is going on, but it exactly what is happening doesn't make sense. I thought the page erase was an atomic thing (once it is started by the softdevice), once you start the erase the CPU blocks until the erase completes. So if the design limit is 22.3ms, it will always cause a missed radio event in the worst case. So it doesn't really matter when you schedule the erase, just wait to the end of a connection interval and start the erase. So where is the ~100ms/page coming from? Is there some additional rate limiting inside the softdevice?

Maybe there is an non-documented interface for erasing a row (256 bytes) at a time. If it does one row per interval plus the time to sync up to the next interval, that could be ~100ms/page.

[Clem Taylor]

Thanks, what is 'scheduling time' for a flash erase, so I can set the interval long enough so as not to trigger the unsuccessful schedule? Is it 22,3ms from the datasheet? How long of a connection interval do I need to maximize the erase speed? At 90ms/interval it is taking ~30ms/page to erase 132 pages.

I guess a ~4s erase is good enough for me to ignore the problem for now.

[Stefan Birnir Sverrisson]

30ms/page erase with 90ms connection interval makes sense to me with the above reasoning, as some page erase commands will be given just before a radio event. In that case, a flash page erase command will be delayed up to ~25ms by the softdevice

[gmaynard]

Tip: you can set the local connection interval to the maximum value while erasing flash and it'll avoid this problem. This is easier than actually trying to renegotiate the connection parameters. Be sure to set it back to 0 before actually writing the flash, or receiving flash data over BLE will be very slow.