We’re working with the NRF52, SDK 14.2 and SES.
Somehow we have managed to have our boot loader extend into our MBR params page. We extended the stock SDK 14.2 boot loader with support for an OLED so we could indicate DFU mode but the memory offsets did not get moved, so the extra 2.5K of boot loader memory now is overlapping into the 4k MBR params page. Our boot loader is currently about 27k instead of just under 24k like the default boot loader. This wasn’t discovered until later because everything is working fine, the boot loader works and application updates (which are single bank due to app size) all work as expected. It was only when experimenting and trying to update the boot loader that I got an insufficient resources error and realized that the boot loader was too large and was overflowing.
Per another thread it seems that the MBR params page is only every used when doing a boot loader or soft device update, but maybe not in any other case. If that is true then it would explain why everything currently works fine even though the boot loader and MBR page are overlapping. So I have a few questions as we figure out how to move forward.
1) If the MBR params page is really never used outside of a boot loader or soft device update then we are theoretically safe to continue as is, with the understanding that we would never try to update BL/SD. App updates work fine and the app itself works fine. We are using FDS storage in the app with quite a few pages, but as long as FDS during normal operation and the soft device during normal operation don’t touch the MBR params page then can we just leave it alone and proceed? We don’t expect to do a boot loader/softdevice update so for now this would be the ideal situation because we could retain the OLED as an indicator of DFU mode. Obviously if at some random point the MBR params page is going to get wiped and that erases 2k of my boot loader then we would have a serious problem that could brick the unit so this is the main situation I want to clarify and avoid.
2) I was able to roll up the stock boot loader which is under 24k and do a boot loader update without any issue. After that update we are presumably in a situation where the MBR params page does not overlap and we could now update the soft device or boot loader with expected results and the MBR could use the params page without any issue. If we pushed on with the current boot loader, but then there was some change or emergency we could always do a boot loader update first to a standard size boot loader and then update boot loader/soft device as expected?
I understand that the real solution would have been to correctly account for the larger boot loader and free up the memory but from my reading it seems that is a tricky/perilous thing to do once the board is already programmed without doing a full erase via a programmer which is not an option.
