Erasing Flash memory with application loaded via open serial bootloader

[Dimitris]

Hello,

we are using an nRF52833 for our application with the open serial uart bootloader and MBR programmed in it. What we would like to do is:

1) program the application via serial bootloader with a temporary firmware (the firmware uses soft device)

2) run the firmware, then enter DFU mode

3) Load the device with a new firmware (erasing firmware) which will erase the previous application, the soft device and itself, but leave the bootloader and MBR, so as to leave the device in its previous condition (only bootloader and MBR loaded in the device).

If possible we would like to interact only via UART with the device (no j-link attached)

The problem lies in step 3. The firmware in step 3 is not using the soft device or any of the Nordic header files. We used GCC toolchain.

Here is what we tried so far, and some questions: 
 3.1) We programmed an empty device without a bootloader with the erasing firmware (Flash set to start at address 0x0) to test if it could erase itself and it could. The erasing function was set to run from RAM. We also tried it with the erasing function not run from RAM and it also worked, which is a bit confusing, we expected this not to work since when the page was erased, it was in use(?) 

3.2) The device was loaded with bootloader, MBR and the temporary firmware(normal case). The erasing firmware was set to run from RAM, using:

__attribute__((used, long_call, section(".ramfun"))) void fun(void)

 

we loaded the firmware in the device using uart. We tried two things with this setup. Only opening a LED (via function loaded in RAM memory), which worked ok (so the function was called). Then in the same function, we added code to erase the memory after the LED opens, and then close the LED when erasing is complete. This did not work (not even the LED opened). Any clues why this could happen? Does the bootloader use something at that time, that prevents the memory from been erased? If that is the case can we do something about this?

Another strange thing happened when using Segger Embedded Studio:
3.3) The function to erase firmware was set to run from RAM again. When the device is loaded with MBR, bootloader and the temporary firmware:
- if we program the erasing firmware via a J-Link debugger through embedded studio, the memory (soft device etc, previous application and the erasing firmware) is erased, leaving the bootloader intact. (in other words it works as it should)
- When the device is programmed via uart using the bootloader, it does not work (it seems to stop when writing to NVMC erase register.

Do you have any idea how/ if something like this can be achieved (program an application via uart bootloader to erase anything but the bootloader and MBR)? 

[Vidar Berg]

Hello,

 3.1) We programmed an empty device without a bootloader with the erasing firmware (Flash set to start at address 0x0) to test if it could erase itself and it could. The erasing function was set to run from RAM. We also tried it with the erasing function not run from RAM and it also worked, which is a bit confusing, we expected this not to work since when the page was erased, it was in use(?) 

It guess it should work if you erase that page last. Is the code that erase the chip is running from RAM?

The function to erase firmware was set to run from RAM again. When the device is loaded with MBR, bootloader and the temporary firmware:
- if we program the erasing firmware via a J-Link debugger through embedded studio, the memory (soft device etc, previous application and the erasing firmware) is erased, leaving the bootloader intact. (in other words it works as it should)
- When the device is programmed via uart using the bootloader, it does not work (it seems to stop when writing to NVMC erase register.

Is the application start address set to 0x1000 and ram to 0x20000008 in your linker configuration so it doesn't overlap with the MBR?

Best regards,

Vidar

[Dimitris]

Vidar Berg said:

It guess it should work if you erase that page last. Is the code that erase the chip is running from RAM?

In this test we tried two firmware versions: One with the code running from Flash and one from RAM. It worked in both cases. This is the last page erased as you mentioned.

Vidar Berg said:

Is the application start address set to 0x1000 and ram to 0x20000008 in your linker configuration so it doesn't overlap with the MBR?

Yes, the linker configuration is like the one you mentioned.

After some more experimentation it seems that the firmware is able to delete most of the pages (soft device, old firmware) but it gets stuck when trying to delete any of the following pages (probably a hard fault):

- The page starting from 0x1000 (where the erasing firmware is programmed): this is odd because the function that erases it runs from the RAM.
- The page that starts from 0x7F000 and 0x7E000 (which as I can understand are the MBR parameters, and Bootloader Settings Pages)

More specifically the problem happens when writing those addresses in the NVMC ERASE register (either one of them, we tried them all).

Is it possible that the bootloader "locks" those pages? Is there a way to bypass this lock? 

[Vidar Berg]

Yes, the bootloader will protect these pages through the ACL — Access control lists, so you should not attempt to erase those.

[Dimitris]

To my understanding the Access control list is configured at startup by the bootloader and cannot be modified afterwards, only after a reset. Since a reset starts again from the bootloader I suppose there is no way to bypass this...

I suppose when we tried to program the erasing firmware with the Segger Embedded Studio and the J-Link, the bootloader was bypassed somehow and the code ran directly from the erasing firmware without setting the Access Control List after the reset(?) That is why the erasing firmware works then.

So my questions are these:

1) Is there a way to modify the Access Control List when the bootloader is used?

2) If there is no way to modify it, then the following cannot be implemented, correct?

Dimitris said:

program an application via uart bootloader to erase anything but the bootloader and MBR

[Vidar Berg]

Yes, it may behave differently in debug mode.

1) 2) There is no way to disable the protection after it has been enabled by the bootloader, so the MBR, bootloader, param page, and settings page cannot be erased.

[Dimitris]

Ok, I see. Thank you for the response!