This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

sd_flash_write implementation without Softdevice

Hello,

I am starting to create a bootloader and I want it to be independant of the SoftDevice. Is there any open source implementation of a flash_write function that I could use? I've noticed that the official bootloader is using sd_mbr_command to initiate the copy process with the help of the softdevice. How is this copy process implemented?

  • Does it begin from the lowest page of the source and does it copy pagewise? E.g. what happens when the image starts at page 100, is 50 pages long and should be moved to page 80.

Thanks, Marius

Parents
  • Hello, attached some simple code I've made earlier that accesses the NVMC directly (blocking). This code can be used when the softdevice is disabled. Note that there is no memory alignment checks implemented here, so make sure to only used word aligned addresses when doing writes, and page aligned addresses when erasing.

    The MBR does not support the scenario you describe. Flash pages has to be erased before storing any new data, which is not the case when reaching the 100th page.The point of having the MBR is to allow the bootlaoder to safely update itself and the SD (SDK bootloader depends on SD to perform DFU). It is not used for application update.

Reply
  • Hello, attached some simple code I've made earlier that accesses the NVMC directly (blocking). This code can be used when the softdevice is disabled. Note that there is no memory alignment checks implemented here, so make sure to only used word aligned addresses when doing writes, and page aligned addresses when erasing.

    The MBR does not support the scenario you describe. Flash pages has to be erased before storing any new data, which is not the case when reaching the 100th page.The point of having the MBR is to allow the bootlaoder to safely update itself and the SD (SDK bootloader depends on SD to perform DFU). It is not used for application update.

Children
  • Thank you a lot, that saved me some time :-)

    I've rewritten both functions and I was wondering why you enable and disable the write / erase mode after each write / page erase. I've checked if I can simply enable the controller, then do multiple writes and disable it again and it works. I've also read through the manual and it doesn't say that we have to re-enable it again after each write. Is there anything I overlooked?

    Also, the manual does not say that we have to check the READY register after enabling write mode, it only says it's busy when ERASE or WRITE is going on, why ist that?

  • It is not required to disable write in-between write operations, but it is important that erase and write is not enabled at the same time as it may result in unpredictable behavior as mentioned in chapter 6 of the nR51 RM. It also recommends to disable write/erase when not actively in use.

    *Also, the manual does not say that we have to check the READY register after enabling write mode, it only says it's busy when ERASE or WRITE is going on, why ist that? * This is not a requirement as far as I can tell. Tried to debug the code, and NVMC seems to be ready as soon as erase/write is enabled.

  • And one more thing: If SoftDevice protection is enabled, that means that the softDevice is in Code Region 0 and my app and the bootloader are in code region one. How will I be able to erase the softdevice?

  • It won't. Softdevice protection shouldn't be used when supporting Softdevice update. Reason is that the code region cannot be changed through DFU. In other words not possible to update to a SD of different size. Also, normally it is the MBR that copies/clears the SD, and it's able to do so even with SD protection as it resides in CR0

  • Cool, thanks a lot. So I assume that a future version of the S130 Softdevice could have a bigger size? (This version hat about 2kb of free space left in its region as I've seen). If the size could change I'll have to revise my bootloader a little. Does the Softdevice have a fixed header that is documented somewhere from which I can read the size?

Related