Minimalist Bootloader S110

[Mostly Harmless]

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.

[Hung Bui]

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

[Mostly Harmless]

Thanks for the response, HB. I'm aware of the differences between the different soft devices. I've made sure to copy the appropriate APIs for each version I've downloaded.

So here's some more info from this morning. I decided to try an example application. I chose the S110 Beacon example. (nrf51822\Board\pca10001\s110\ble_app_beacon) After getting the example to compile, I received an error when downloading to the evaluation board. (Programming failed @ Address 0x00000000 (Block Verification Error)).

Using J-Link Commander, I erased the chip again. As shown in the attached image "Erase" (Erase.png) the mem command shows the device is erased. I unplugged the evaluation board from the USB cable, plugged it back in, reconnected with J-Link Commander and dumped the first 0x200 bytes again, shown in attached image "Reset" (Reset.png). They're not erased any more. The data looks like garbage too. This process can be repeated over and over.

I'll continue working on this. I'm definitely open to other suggestions.

[Hung Bui]

@Harmless: Next time please edit your question to add more information instead of creating an answer, because it's not an answer. Address 0x00000 is where the softdevice located, the application should not be programmed there. If you are using S110 v7.x you would need to locate your application at address 0x16000. In KEIL it's the IROM1 start address configuration.

Also you would need to flash the softdevice before you program your application. What you described with Jlink is pretty strange, have you tried to use our nrfjprog.exe tool to flash the hex and also can read/write on the flash ?

[Mostly Harmless]

HB, sorry, I'm new to your forum. I meant my comment to be a response to yours. I'm not flashing my application to 0x00000000. I'm flashing the soft device to 0x00000000. As I said, I had this working before. My application is going in at 0x1A000. I've swapped out my Evaluation Board for a different Evaluation Board of the same type. So far, so good. I flashed in the v7.0.0 s100 soft device, and am using the v6.1.0 SDK. It looks like I'm back to where I was before all this started. I'm not exactly sure what happened. It appears that the nRF chip may have gone toes up during a re-flash of the part? Strange coincidence if so. We're going to swap the nRF chip out and retry the board to see if it's him or the Segger chip (or possibly something else wrong with the board).

[Hung Bui]

Hi,

I assume that you have written in UICR at address NRF_UICR_BASE + 0x14 the address of your bootloader: 0x1A000. Note that if there is nothing written at that address, the interrupt will be forwarded to the softdevice instead of the bootloader.

Have you tried erasing&writing with nrfjprog.exe ?