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

Softdevice Update OTA

Hi all,

I have various questions regarding the softdevices, memory management and power consumption of the nrf51822 chips.

The project we are working on will need to update the softdevice depending on the use case... This should be done over the air. From what I have seen in the forum and the chips specifications this is not a trivial procedure, as the bootloader in region 1 doesn't have the ability to write/erase on region 0. Would it be possible to have this API in the softdevices? Or better yet, the source code of the softdevices to implement it? Having the source code would also give us more flexibility and optimisation over the MAC and APP layers...

Also the S110 specifications give us the power profile of the chip in the various modes. Is this available for the S120? (Not in the S120 specifications).

We would also need to have some kind of network between various devices, but in S120 a central only supports up to 8 peripherals. This limits the communications between those 8 (or less) devices to a central, right? As a device cannot be a central and a peripheral at the same time I guess there is no possibility of having some kind o mesh/multi-hop network, right? At least without changing the soft device...

ERASEALL register erases all the chip? Region 0 and 1? Is it accessible from code in Region 1? (This would also mean the bootloader would be deleted...)

Readback protection on Region 1 is just for readback? Or when active it also means that the bootloader is not able to write in that Region?

Using a bootloader makes the softdevice redirect the interrupts to the bootloaders reset address, which then if a valid App is present requests another interrupt forward to the APP's reset address. Having two (or more) APPs in memory would be possible, as long as during the init process the bootloader redirects the interrupts to the correct APP (their reset address), right?

Besides that, one of the use cases is for Location, which needs calibrated output power from the system. This means we need several devices transmitting with the same power in the same test conditions. Furthermore, the power control of Nordic chips work in steps (5 steps from -20dBm to +4dBm if I'm not mistaken), how can we ensure that these steps transmit with the same power? We need to calibrate them somehow, to guaranty the same output power level... Bitrates are not really important here, so there is no need to control the chip transmit power to meet any bitrates...

Thanks, Diogo Digital Logic

  • Doing a softdevice update is as you say not trivial with the current softdevices. They do however not require that CLENR0 is set anymore, so you can in theory not set this, and then do erases as needed from a bootloader. ERASEALL would still erase the complete chip, but you could erase a softdevice page-by-page, while keeping the bootloader. However, if you lose power right after having erased page 0, before you have written a new softdevice, you will brick your device since this is where the vector table is. Future softdevice will include functionality to avoid the need to erase this page, so that such upgrade can be done safely.

    Even so, updating a softdevice is a significant effort, that requires transferring significant amounts of data (> 80 kB), so I would be careful about making an application relying on doing this regularly.

    Readback protection disables only readback, not writing. If you want to protect an area against writes, you'll have to use the PROTEN register in the MPU.

    To have two applications on one chip, you'd currently have to implement interrupt forwarding in the application located right on top of the softdevice, to whichever application is currently running.

    The accuracy of the TX power is specified to be +-4 dBm, both due to chip-to-chip variations and due to the tolerance in the matching network components. This should however not have a significant effect on performance. There isn't really any correlation between output power and bitrate, and with BLE, the bitrate is fixed at 1 Mbps anyway.

    If you have follow-up questions, I'd be happy you post them separately, as separate questions when they have to do with different topics; having everything in one question tends to become very messy over time. :-)

Related