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

About MBR area of softdevice

Hi, I'm using s130 as softdevice for nrf51822. I program the softdevice with the official s130 hex file. According to the hex file, there is no data at address from 0x7c0 to 0x1000. This is the reserved area for MBR. So I don't want to touch this address area, and just program other area with data. But the chip is finally stuck at the address 0x596 if there is some old data left at the area from address 0x7c0 to 0x1000. If I erase this area or just set the area to 0. Then the chip works file.

So looks like we have to set the area from address 0x7c0 to 0x1000 to all 0x0 or 0xFF data, otherwise the softdevice can't work fine.

My confuse is why we have to clear this area? Looks like this is a useless area, and should not effect anything. If we have to clear this area, then does it mean we should add this information to hex file of s130?

Parents Reply Children
  • Hi, I program some invalid binary file to the FLASH to override the softdevice area firstly. Then I try to program the softdevice hex file into the flash. When programming the softdevice I just ignore the reserved area from address 0x7c0 to 0xFFF according to the s130 hex file. Then this area(0x7c0 to 0xFFF) will keep the old invalid data. Then I program and run my application with this softdevice. It can't work fine and get stuck at the address 0x596. I tried to erase the reserved area(from address 0x7c0 to 0xFFF) to 0xFF, or set this area to all 0x0, then everything works fine. Theoretically this area should not effect anything since it is useless area according to the s130 hex file. The hex file has ignored this area. But from my test, looks like this area has effected the running of the softdevice. Why can this happen?

  • The first 0x1000 bytes of softdevice is reserved for MBR. Since the size of MBR is 0x7c0 and is smaller than 0x1000 bytes, there is some useless area(from address 0x7c0 to 0xFFF). Theoretically this area can be any data, since it is useless area. But my test result is that if I set this area with random data the softdevice can't work fine, and it has to be set to all 0xFF or 0x0. I want to know the rootcause for it.

  • The MBR handles flash operations, which means that it can write to any location of the chip. Even if there is no indication from the .hex file that there should be data in that section; it may still write something to the higher area using the NVMC peripheral. I would strongly recommend not altering the MBR or the softdevices address area in general.

  • Hi Håkon, Thanks for your reply! But looks like I still haven't got the answer for my confuse. What kind of data should be programmed into this higher area of MBR? The flash tool programs the flash through SWD interface according to the hex file, and will ignore this area since there is no indication for it in hex file. But it can't work if there is some old data in it, we have to erase it or set it to all 0x0 as I tested. If there is some requirement for setting this area to some special values(all 0 or 0xFF), it should be indicated in hex file. Why the hex file ignore it? Even if NVMC peripheral could write to this area, it should just erase this area and write new data. The old data should not effect.

  • Well I don't know this for a fact, but what I "assumed" is going on is the MBR is using some of that space for NV storage. Nordic claims that the MBR will make sure a boot loader or soft device is completely copied over. For it to do that, the MBR is going to need to save some information in case the device loses power during the operation. My guess is the last 1K of memory at 0xc00 to 0xFFF is probably used for this purpose. My guess is when you issue the MBR command to copy the soft device, the MBR probably erases that 1K of memory, and then writes some information regarding the copy it is about to do. Then it copies the memory. If there is garbage in that section then when the MBR boots up it probably thinks it needs to copy the soft device and since it is garbage it hangs somewhere.

Related