Bootloader overlapping MBR params page, should we worry?

[dmf3030]

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. 

[Susheel Nuguru]

Hi Duncan,

1) Your assumptions are correct about when the MBR params page is being used. You app updates would work fine even with the overlap. But I think that BL/SD update will be risky (unpredictable) with an overlapping bootloader into MBR params page. I would caution you with one more thing. 

• When the system is booting up, the first thing that is run is the MBR reset handler.
• In the MBR reset handler, MBR param page is sniffed to see if there is a valid header  at ((NRF_UICR->NRFFW[1]) + 5). If this value is 0xAA by coincidence from the overflow of your bootloader then the MBR reset handler would think that this is a valid page and do a CRC check on the rest of the MBR params page. If the CRC check fails, then it would erase the params page and do a system reset. You would not like this as this will erase part of your bootloader. So make sure that the given offset never contains 0xAA.

2) If you try to upload the bootloader first then it would try to reinitialize the MBR param page (which is OK as you do not care about the old bootloader being overwritten)  I am still a bit paranoid here, but seems like it should work. Never tried it though

[dmf3030]

Aryan, thanks for the help & info!

Seems like our safest course of action is to flash the revised bootloader that correctly fits in the alotted memory.  We have done this updated repeatedly over our old "too large" bootloader without any issue.  We have then moved along to update the application and found no problems.  I did find it odd that flashing the bootloader did not erase our application like I expected.  I did not think we had enough free space for a dual bank bootloader update since we have a large chunk reserved for FDS storage. Maybe if those pages are not used yet then they can be used for the update, that or we have a bit more memory than I expected and dual bank is possible. I'm also a bit paranoid here butI feel like the best route is to flash the new bootloader while we have the units in hand and can ensure that everything goes well. 

The other option is to let the units get into the wild with the "too large" bootloader which obviously does not have the problem with 0xAA at the magic spot in the MBR page since it works for now.  Seems like if the units are currently working theres no reason they should suddenly develop an issue where 0xAA ends up in the wrong spot, but this still makes me nervous and I don't like the idea of the questionable bootloader update ever happening in the wild. 

Q: So with the assumption that we will be updating the bootloader to be the correct size,  my only question is about what happens to the old bootloader code that overlapped into the MBR.  When we flash the smaller bootloader it presumably erases the bootloader memory bank but I would doubt it erases the MBR page, (though if it wrote there then maybe its happy to erase into it too).  So after our bootloader update there could still be old bits of code in the MBR, but if I understand correctly the worst thing that can happen is that code eventually causes a bad CRC in the MBR params page which just leads to it getting erased and a system reset. After that we would be all good with no signs of the mistake and a clean MBR page. I'm not sure how the MBR is used for a soft device or bootloader update, could that bad MBR checksum happen after we have sent over a new soft device and cause a bad update?  When does the NRF deliberately write that 0xAA value to the MBR params page, seems like the first time that happens we would have a problem unless prior to writing it the page is erased by the NRF.  

Thanks!

[dmf3030]

Another related question would be whether the stock 14.2 SDK bootloader has any code that can be cut to reduce the compile size so that I could still squeeze in the extra 2k of code I need to run an oled with my bootloader.  In stepping through the memory usage I don't see much fat to cut, we're not using any of the bsp code but mainly I'm seeing the uECC library taking up space and I expect theres not really anything to omit there. 

[Susheel Nuguru]

Hi Duncan,

I checked the code and to answer your question, it does not erase MBA param page when you are uploading a smaller bootloader (replacing your oversized one). So this should work fine.

[Susheel Nuguru]

I do not think that there is much fat to cut there in bootloader templates that we provide.

Yes, you are correct, uECC is needed for secure bootloader to decrypt the signatures.