How to fix bugs in shipped products when DFU is not possible?

[Michael Dietz]

I have a product that was released a few months ago and is operating in-the-field. Recently we discovered a bug and need to fix it. We are unable to do a DFU because:

• There isn't enough free FLASH.
• We can't afford to replace the entire FW image just for this small fix.
• Our product can't stop operating for a minute while we switch to DFU mode and do the update.
• Some of our FLASH is one time programmable and we can't reprogram or modify it.

Are there any options?

[Michael Dietz]

Using the Flash Patch and Breakpoint Unit is an option. This is available on ARM Cortex-M3/M4.

Short, simple example: All calls to buggy_function() can be redirected to fixed_function() using the FPB.

Please see this GitHub repo for more information. The readme explains the FPB and its use cases. There is an example demonstrating it's use and a library.

github.com/.../nRF52-flash-patch.

[Michael Dietz]

More explanation:

Not enough free FLASH - fixing a bug in the SoftDevice will require a dual bank DFU normally (so you will need around 100kb of free flash to fix a bug in the SoftDevice with DFU). With a flash patch you can just patch a specific function with <1 KB of free FLASH required.

Product can't stop operating during DFU: Normally when doing a DFU the application needs to switch from application mode to bootloader mode and perform the update. During this time, the application is not operating (if its a step counter it isn't counting steps). In more serious cases this can be unacceptable. With a flash patch the application could have a BLE service that receives the patch and stores it in flash, then restarts the device. The device is always in application mode in this case.