• State Verified Answer
  • Locked Locked
  • Replies 5 replies
  • Subscribers 62 subscribers
  • Views 4264 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 103755
Options
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Protect bootloader from overwrite/erase

Eric Salem

I am using Nordics sample bootloader and I really want to make sure that given a freak accident in sending it the firmware or in the firmware code itself that the bootloader is never erased or overwritten. In its current state, is the bootloader protected against that or are there measures I can take to accomplish it?

I have also noticed the call sd_flash_protect, but I am not sure if that is the proper approach and if so how to use it.

Thanks,

Parents
  • 0

    You can use the registers PROTENSETx to protect you bootloader. If you have enabled the softdevice these registers are accessed through the sd_flash_protect call. PROTENSETx enables you to protect 64 different blocks of the memory. For the nRF51x22 these blocks are 4 k big.

    Update: main.c I edited the standard .../nRF6310/S110/bla_app_hrs example. The main file is above here. I added code to set the PROTENSET and protect the upper half of flash and then try to write to that area. It fails and gives me an error code.

    UPDATE 2: Always make sure that you are using nRF51 of second revision if you are using sd_flash_protect() or PROTENSET. On nRF51 revision 1 this functionality is not available.

  • 0 in reply to Asbjørn

    I finally was able to see the behavior you are describing and I had to change the chip and use a nRF51822 revision 1. It's marked with N51822, QFAACA, 1230AA. The second line is the important one here, on revision 1 of the nrf51822 it will say QFAACx, where x can be A or 0. I do suspect that the chip you are working on are marked with CA or C0 and hence a revision 1 chip.

    I've been testing this on revision 2 of the chip QFAAGx and this is the first version where the flash protect was implemented and hence I have not be able to recreate the behavior you see as expected.

Reply
  • 0 in reply to Asbjørn

    I finally was able to see the behavior you are describing and I had to change the chip and use a nRF51822 revision 1. It's marked with N51822, QFAACA, 1230AA. The second line is the important one here, on revision 1 of the nrf51822 it will say QFAACx, where x can be A or 0. I do suspect that the chip you are working on are marked with CA or C0 and hence a revision 1 chip.

    I've been testing this on revision 2 of the chip QFAAGx and this is the first version where the flash protect was implemented and hence I have not be able to recreate the behavior you see as expected.

Children
No Data
Related