DFU in custom board without Segger

RE: DFU in custom board without Segger

Nguyen Hoan Hoang — Wed, 01 Jul 2015 21:44:42 GMT

For flashing with micros, the softdevice hex must be named Softdevice.hex, Application must be name firmware.hex and DFU is named dfu.hex. No mergehex. Just rename the all 3 hex to the appropriate name. The IDAP-Link firmware will take care of the rest. After successful programming, it will attempt to start the device. If programming failed, the Red LED will blink at about 1 Hz. It is not require to have all 3 files. You can have just Softdevice + firmware or Softdevice + dfu or just one file.

RE: DFU in custom board without Segger

Dani — Wed, 01 Jul 2015 13:33:26 GMT

Now it is perfect, thanks. Furthermore, when using the micro SD card: which files should be included into the card... a) softdevice + bootloader + application (hex files)? b) one file created with a merging tool that includes all three mentioned above?

RE: DFU in custom board without Segger

Nguyen Hoan Hoang — Wed, 01 Jul 2015 00:23:51 GMT

Yes, there was a bug with the Windows version of the IDAPnRFProg. It filled the empty spaces with 0. It has been fixed in version 0.5. You can download it from here.

RE: DFU in custom board without Segger

Dani — Tue, 30 Jun 2015 15:32:46 GMT

(continues) The only problem I have is related to Data-Peserving: when my device starts, I only write flash with my default values if it is not written (when 0xFF). I also use DeviceManager, I have PSTORAGE_MAX_APPLICATIONS to 5, and DFU_APP_DATA_RESERVED is set to 0x1400. If I try to read flash later on, I get all values to 0, so it means that it has not written with my default values and it seems as it was initialised to 0x00. Any suggestion???

RE: DFU in custom board without Segger

Dani — Tue, 30 Jun 2015 15:29:51 GMT

I purchased the tool you have suggested and, once received, I have proceeded as follows:

First, I have taken the example '...\examples\dfu\bootloader\pca10028\dual_bank_ble_s110\arm4' from the SDK, and I have compiled it with the following memory mapping: - IROM1: 0x3C000, 0x3C00 - IRAM1: 0x20002C00, 0x5380 - IRAM2: 0x20007F80, 0x80 (noinit)
I have also compiled my application with this other memory mapping: - IROM1: 0x18000, 0x24000 - IRAM1: 0x20002000, 0x6000
Then, and by means of the IDAP_link and IDAPnRFProg I have successfully programmed my device.
My device works fine and I also succeeded in changing my application by using the DFU utility. But... (continues)

RE: DFU in custom board without Segger

Nguyen Hoan Hoang — Thu, 18 Jun 2015 22:23:58 GMT

The addresses are in the hex. The IDAPnRFProg takes care of all that automatically.

RE: DFU in custom board without Segger

Dani — Thu, 18 Jun 2015 07:24:45 GMT

It looks fine. But, how can you specify memory location adresses? Are they included into hex files?

RE: DFU in custom board without Segger

Øyvind Karlsen — Thu, 18 Jun 2015 07:01:37 GMT

This is shown in this blog post.

RE: DFU in custom board without Segger

wlgrd — Thu, 18 Jun 2015 05:52:24 GMT

If you have a Development Kit you can use the debug out functionality of that one.

RE: DFU in custom board without Segger

Nguyen Hoan Hoang — Wed, 17 Jun 2015 23:55:26 GMT

How about this alternative here. multi-boards can be used for parallel programming on OS X & Windows. Can Flash all 3 (SD, App, DFU) all at once without mergehex. Support drag & drop with support for mBed compiled hex. Lot's features.