• State Verified Answer
  • Replies 3 replies
  • Subscribers 73 subscribers
  • Views 1746 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 200222
Options
Beware that this post is related to an SDK in maintenance mode
More Info: Consider nRF Connect SDK for new designs
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Write flash address 0x0000 to 0x1000

NewAce

I'm working on a bootloader using the /examples/iot/bootloader as an initial template. The image to flash is stored on SD card. I'm at the point where I am successful in writing the image to the internal flash of the NRF52832 only if I skip writing the region 0x0000 to 0x1000. The image boots afterwards fine when I do this (and I confirmed that I am actually running the flashed image) but I am concerned that if my image includes a new softdevice that it will no longer start my application properly. I suspect that certain reset/interrupt vectors are stored in the 0x0000-0x1000 range that I need to divert first before I can write those areas. Can someone shed any light on how to write to this area without causing the bootloader to lockup? Many thanks.

Parents
  • +1

    The region you are describing is what is known as the "MBR" or "Master Boot Record". It is typically distributed as the first page of the SoftDevice, but it is really a standalone piece of firmware responsible for a very limited set of operations right after the device is powered on. If this firmware is corrupted there is no way of returning the system to a working state, and for this reason, you should never erase this flash page.

    When the Nordic nRF5 SDK DFU bootloader updates the SoftDevice this 4K block is never affected, and your custom bootloader shouldn't either.

    Figure: An arbitrary memory map from a page in the documentation showing the MBR.

    Best regards,
    Rune Holmgren

Reply
  • +1

    The region you are describing is what is known as the "MBR" or "Master Boot Record". It is typically distributed as the first page of the SoftDevice, but it is really a standalone piece of firmware responsible for a very limited set of operations right after the device is powered on. If this firmware is corrupted there is no way of returning the system to a working state, and for this reason, you should never erase this flash page.

    When the Nordic nRF5 SDK DFU bootloader updates the SoftDevice this 4K block is never affected, and your custom bootloader shouldn't either.

    Figure: An arbitrary memory map from a page in the documentation showing the MBR.

    Best regards,
    Rune Holmgren

Children
  • 0 in reply to Rune Holmgren

    - thanks for your comments. Can you confirm that the MBR for softdevice version 2.X is identical to that of version 3.X, 4.X and 5.X? We're using S132 version 2.0.1 with mBed for our main application and SDK v14.2 for our bootloader. I would like to be able to replace the softdevice at a future date and need to make sure that this is possible even though we are not updating the MBR. Please confirm. 

  • +1 in reply to NewAce

    The MBR in S132 v2.x, v3.x, v4.x, and v5.x are all forward compatible and support updating the SoftDevice without changing the MBR. It's identical in v2.x, v3.x, and v4.x. In S132 v5.0.0 a new MBR command was added (SD_MBR_COMMAND_IRQ_FORWARD_ADDRESS_SET), but all existing functionality is unchanged. The use of this new command is optional and it's perfectly fine to run S132 v5.x with the older MBR versions found in the mentioned SoftDevices.

    While I can't give any absolute guarantees for future releases, we are aware that incompatible MBR changes would prevent existing products from upgrading. We will continue to make great effort finding non-breaking ways of implementing any changes.

    Best regards,
    Rune Holmgren

Related
Terms of service