over the air versus Jlink programming

[wim]

Hi

I have been reading for a few days now, through the nrf51 documentation, the forum, and getting a bit of a grip on the proposed concepts in the DK. However, what I do not really get yet is the following: is the over the air programming equivalent to programming using a Jlink? And how does the soft device fit into this? Should I see the soft device really as a separate program? Is it programmed to the flash separately?

As an example: If I want to put the blinky example project, on the beacon kit hardware, over the air, will that work? Will the boot loader then be removed, or is it also sitting there separately? Or can I only program the blinky example project to the beacon kit via a Jlink programmer? Does the blinky example use the actual soft device stack? Or is it just a basic single file 'hello world' type of controller project?

Or is it more like I am used to on simple controllers: the soft device is just a piece of flash which is merged into the main flash. But what about the wireless flashing then? Is that really a boot loader in a protected part of the flash? And how is a device put in 'boot loader mode'?

Maybe all obvious or silly questions, but I just did not find an answer. Maybe the confusion is caused partly because of the difference between the nrf51 DK on one hand, and the beacon kit on the other hand. The beacon kit does not give access to the SDK, while for the nrf51 DK, the SDK is the basis. Is the embedded software of the beacon kit example a sub set of the SDK?

Can anyone clarify?

[Nguyen Hoan Hoang]

Softdevice (s110, s120, s130) is the Bluetooth/Ants stack. A library or see it as pc bios services.
There are 2 kind of blinky examples. one without ble which is plain hello world kind of stuff. It does not use softdevice, though require jlink to flash. The other which is BLE need softdevice loaded. The BLE dfu allows you to upload the blinky BLE over the air but not the hello world. You can also use link to flash the blinky ble as well.

Blinky hello world is located at address 0,

Blinky ble is located at 0x16000, bellow Softdevice as ~80K starting from address 0

[Vidar Berg]

Hi,

Over the air programming has the advantage that it lets an end user update the FW via e.g. a smartphone if needed. This gives the developer an opportunity to release updated FW to existing users.

The beacon kit comes pre-programmed with a bootloader and the softdevice as opposed to the development kits. This is required for enabling over the air firmware update. Otherwise you would have to program the bootloader+softdevice with a J-link for the first time programming in order to enable OTA programming for later use. I recommend spending some time reading DFU documentation here to get a better understanding of the DFU concepts.

Using a J-link programmer is more suited for development as it offers much more debugging features and flash download speed. The development kit comes with an on-board Segger J-link lite programmer. So normally you would use this during development of your firmware, and add the DFU as an additional product feature.

Any Segger J-link programmer can be used to program the beacon kit. See chapter 5.5.4 in Beacon UG for the appropriate connector. Note that the nRF51 DK has a "debug out" header that can be used to target external boards with nRF51 chips as well.

The memory arrangement with softdevice s110, bootloader and application is described in chapter 9 and 10 in S110-SDS

[wim]

Ok, I will read the DFU documentation. Maybe you could answer this quick question: Just to have a starting point, as I have not received the DK yet (it is on its way), I wanted to try the following: compile the blinky example, change the IO's to match the LED's on the beacon kit, and then use the over the air programming feature of the beacon kit to program the beacon kit with the blinky example. Would this work?

And a second question: the programming via Jlink, is it just 1 hex or bin file which is programmed, for boot loader, soft device and application, or are these 3 things programmed separately?

[wim]

Ok, almost clear. I understood that on the beacon kit, then soft device is already programmed on the device. But I still have these questions:

• when using able dfu to upload the blinky ble example, is it only transferring the application then?
• at what position does the processor start? is the boot loader handling this?
• and do I need to embed something in the application to be able to switch back to dfu, or is the soft device handling that autonomously?
• when I program the device using a Jlink, do I need to program soft device, boot loader and application separately, or are they combined during the build stages?
• do I need the nRFGo tool for this, or can I do this also from Eclipse?

[Nguyen Hoan Hoang]

When you OTA Blinky ble. It is only the blinky that is uploaded, no change to the rest. Ble applications start at address 0x16000. The DFU will put it in the right place. So you need to set that has start address when you create a ble firmware. The DFU example by default uses a gip as button for switch back to DFU mode. It also possible from your application to add code to switch back. You need to look at the doc for details. Eclipse cannot flash the softdevice directly. You an external tool for that. Eclipse can be used to develop and debug your app. This blog site will get you started with Eclipse development with nRF51. http://embeddedsoftdev.blogspot.ca/p/ehal-nrf51.html