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

Minimalist Bootloader S110

Background :

I'm working with an nRF51822-EK development board. We're working on a project implementing the S110 soft device. We need to create a minimalist Bootloader. All we want to do is implement our own proprietary serial (UART) protocol to erase and write our application.

I had been (mistakenly) developing with the S120 soft device. I was able to use Segger's J-Link Commander to flash the image (s120_nrf51_2.0.0_softdevice.hex) into the part on the development board. I was able to initialize the soft device, and tell it to pass interrupts to my bootloader. All seemed to be working well. It was brought to my attention that I should be using the S110 soft device. I erased the part, and flashed the S110 soft device (s110_nrf51822_6.2.1_softdevice.hex).

Current :

Now all functions that call the soft device for configuration (sd_mbr_command(), sd_softdevice_disable(), softdevice_handler_sd_disable(), sd_softdevice_vector_table_base_set()) just "lock up" the device. What really happens is that execution wanders off into code space that makes no sense.

I have tried the above soft devices, as well as s110_nrf51822_7.1.0_softdevice.hex. In all cases, I can erase the part with J-Link Commander, and use "loadfile" to flash the part with the target soft device.

I've even tried re-flashing the original S120 soft device and I can't even get that back to working. Have I somehow damaged the part by erasing and reflashing? I can't imagine that I could have.

Further :

I'm using IAR v7.30. I've edited my icf file to push the start of my boot loader up to 0x1A000, I'm also passing that address via sd_softdevice_vector_table_base_set(). As I mentioned, it was all working at one point, but I cannot even get back to that point.

Parents
  • Hi,

    I don't think writing and erasing the chip can cause any damage (except if you wear it out with 20.000 erase-write cycles). Note that there are differences between S120 and S110 in term of API and the MBR. S110 v6.x doesn't have an MBR to support softdevice update. The API header files are also differents. S110 v7.x has the MBR and is closer to S120 but not the same, so you need to update the API header files.

    I would suggest you to test by simply flash a S110 v7.x softdevice and then flash a normal example we provided in our SDK just to make sure the chip is working fine.

    You can try to use S110 v8.0 which has the same APIs list as the S120 v2.0. However it's aimed at chip version 3. If you use chip version 2 you would need to call the option api to enable CPU lookup when softdevice is active.

    Please be aware that we do provide an UART bootloader in our SDK v7.x that works with S110 v7.x

Reply
  • Hi,

    I don't think writing and erasing the chip can cause any damage (except if you wear it out with 20.000 erase-write cycles). Note that there are differences between S120 and S110 in term of API and the MBR. S110 v6.x doesn't have an MBR to support softdevice update. The API header files are also differents. S110 v7.x has the MBR and is closer to S120 but not the same, so you need to update the API header files.

    I would suggest you to test by simply flash a S110 v7.x softdevice and then flash a normal example we provided in our SDK just to make sure the chip is working fine.

    You can try to use S110 v8.0 which has the same APIs list as the S120 v2.0. However it's aimed at chip version 3. If you use chip version 2 you would need to call the option api to enable CPU lookup when softdevice is active.

    Please be aware that we do provide an UART bootloader in our SDK v7.x that works with S110 v7.x

Children
No Data
Related