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.

[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 ?

[Mostly Harmless]

Yup.

const unsigned long UICR_ADDR_0x14 @ (NRF_UICR_BASE  + 0x14) = FLASH_BOOTLOADER_START_ADDRESS;

FLASH_BOOTLOADER_START_ADDRESS is defined in another file as 0x1A000. It's looking like the answer to this question is that the chip itself had an issue. This one could probably be closed out.