over the air versus Jlink programming

RE: over the air versus Jlink programming

Nguyen Hoan Hoang — Fri, 09 Jan 2015 15:55:14 GMT

Follow my blog page to setup Eclipse environment. Once you have created your project and build in Eclipse, go to the run menu and debug configuration to create a new debug coffin in the GDB Segger section.
nRF51 development with Eclipse

RE: over the air versus Jlink programming

wim — Fri, 09 Jan 2015 15:02:09 GMT

I have my kit now - apparently i did not order the nrf51sdk but an nrf51833-DK, which comes with a separate J-link Lite; so, I have built the blinky-ble example, and want to start debugging or do programming from Eclipse. What do I do? How do I tell eclipse to go via the jlink and start debugging? and how do I just program, such that it runs the compiled code after reset?

RE: over the air versus Jlink programming

Nguyen Hoan Hoang — Wed, 07 Jan 2015 15:07:31 GMT

Yes, you can use your DK with Jlink to develop and debug your firmware in Eclipse. Only thing you need with nRFgo is to Flash in the Softdevice and that need to be done once only. There are many pages on my Blog. One of which will guide you through setting up Eclipse Environment which include plugins for both JLink & OpenOCD. Since you have JlInk, OpenOCD is not needed. All the DK/EK have JLink builtin.

RE: over the air versus Jlink programming

wim — Wed, 07 Jan 2015 14:38:33 GMT

Hi Nguyen, I have read your blog. But still have a question about programming. I have a nrf51 DK, so I can use Jlink as hardware interface, do not need the OpenOCD. If you say I can debug in eclipse, how does this connect to the target then? Via the Jlink I assume? So can't this same interface be used for programming? And can't this be triggered from within Eclipse?

RE: over the air versus Jlink programming

Nguyen Hoan Hoang — Wed, 07 Jan 2015 11:43:52 GMT

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

RE: over the air versus Jlink programming

wim — Wed, 07 Jan 2015 09:06:37 GMT

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?

RE: over the air versus Jlink programming

wim — Tue, 06 Jan 2015 17:07:21 GMT

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?

RE: over the air versus Jlink programming

Vidar Berg — Tue, 06 Jan 2015 16:44:13 GMT

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

RE: over the air versus Jlink programming

Nguyen Hoan Hoang — Tue, 06 Jan 2015 16:32:23 GMT

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