The DFU operation scenario.

RE: The DFU operation scenario.

Vidar Berg — Wed, 17 Feb 2016 07:30:37 GMT

You can program all three using a programmer by setting the app valid flag. This will save time in production, see question 'E' in this FAQ for more details.

RE: The DFU operation scenario.

jsna — Tue, 16 Feb 2016 09:56:41 GMT

Dear Michael Dietz .

One kinds are more curious.

Note that you cannot just flash solftdevice+bootloader+application as normal

-> After downloading binaries produced(Product Launch) by sd+bl , should I upgrade to dfu Application. After downloading the three binaries(softdevice + bootloade + application) , Is there any way to properly look uart application?

thank you.

RE: The DFU operation scenario.

Michael Dietz — Tue, 16 Feb 2016 08:35:23 GMT

OK. That means your bootloader application is running and not the UART app. When bootloader app is advertising LED1 and LED3 are lit. When it is connected LED1 and LED2 are lit.

You probably want the UART application to be running and have your bootloader there if you want to do a DFU update. Note that you cannot just flash solftdevice+bootloader+application as normal. You need to flash softdevice then bootloader and then run in bootloader mode (LED1 and LED3 lit). then you connect to DFU Targ and you need to program the ble_app_uart application by DFU. Then after you do this you will see your uart app run.

There is alot on this. it is possible to flash teh application with sd+bl like normal but you need to write a flag in flash to tell the bootloader a valid app is present on the device. search dev zone for this

RE: The DFU operation scenario.

jsna — Tue, 16 Feb 2016 08:27:21 GMT

Dear Michael Dietz .

•If only the binary download s110_nrf51_8.0.0_softdevice.hex + ble_app_uart_dfu.hex
-> The lights turn on led 1.

-> Nordic_UART display.

s110_nrf51_8.0.0_softdevice.hex (softdevice) + nrf51422_xxac.hex(bootloader) +
ble_app_uart_dfu.hex(application) -> When downloading sequentially, The lights turn on led 1 and Led 2. -> DfuTarg display.

thank you.

RE: The DFU operation scenario.

Michael Dietz — Tue, 16 Feb 2016 08:07:49 GMT

This is because of caching occurring on the smartphone application. I'm guessing you are either using android or iOS Master Control Panel. Try closing master control panel, disabling bluetooth, re enabling it and then starting master control panel again and scanning for the uart application. Now you should see the name is Nordic_UART.

If you use PC Master Control Panel you probably won't see this problem.

RE: The DFU operation scenario.

jsna — Mon, 15 Feb 2016 13:20:19 GMT

hi.

The reason that shows "DfuTarg" It looks like one caused by downloading the bootloader(nrf51422_xxac.hex).

Finally I downloaded a uart application(ble_app_uart_dfu.hex), Why did the name come "DfuTarg" ?

RE: The DFU operation scenario.

Michael Dietz — Mon, 15 Feb 2016 12:31:50 GMT

Short answer: Things get cached a lot with BLE. You will notice this all the time when you develop. Maybe you change the device name, advertising data, service info etc.. and it will still have old value.

Really the only way I've found to workaround this is to disable and re enable BLE (when using phone applications). With master control panel PC application this isn't a problem because you can reset your usb dongle and re discover services as you need to.

Maybe someone has a better answer.. But i see this a lot and haven't found a great way with the smart phone aps.