Problem in switching to DFU mode without button pressed (custom board)

[sidekick]

Hi,

I have a custom board with nrf51822QFAA(256K flash) and I'm trying to test DFU-OTA (BLE transport) for an application. With only Softdevice and bootloader installed, I was able to successfully flash the application(application.hex) using DFU profile in nRFToolbox. More info can be found here.

Now I'd like to put NRF51822QFAA into DFU mode, with an existing application (say ble_app_hrs_dfu application from the SDK V6.1.0). As this is a custom board, It does not have button #7 (as mentioned in the sample application) to enter into DFU mode. Currently I'm stuck at step 2 of the Testing as the target board(which after flashing is advertising as Nordic_HRM) fails to complete service discovery, with Nordic Master control panel (android v2.1.1). As on this custom board, there is no external oscillator, hence updated ble_stack_init in bootloader(also from the SDK v6.1.0) as:

SOFTDEVICE_HANDLER_INIT(NRF_CLOCK_LFCLKSRC_RC_250_PPM_2000MS_CALIBRATION, true);

and similarly ble_stack_init in application (ble_app_hrs_dfu) as:

SOFTDEVICE_HANDLER_INIT(NRF_CLOCK_LFCLKSRC_RC_250_PPM_2000MS_CALIBRATION, false);

Steps:

• Erase all using nrfjprog.exe
• Flash SD (v 7.1.0) using nRFGO Studio
• Flash bootloader using KEIL uVision, J-link and nrfjprog.exe
• Program the application using using KEIL uVision, J-link (without using nrfjprog.exe)
• Write 0x1 at the address 0x03fc000(BOOTLOADER_SETTINGS_ADDRESS) using nrfjprog.exe
• Observe that the device now advertises as Nordic_HRM
• Attempt to use MCP to switch into Bootloader mode (DFU_Targ)
• Result: Service discovery fails

Attached here is the log file generated by nRF Logger. (Note: Device address is modified in the log file to preserve the identity).

Log 2015-06-08 18-13-33.txt

[Hung Bui]

@Sidekick: Using nrfjprog.exe --memwr to write to 0x03fc00 is just a hack. It's not how the bootloader inteded to work. What is designed, is that after you flash the bootloader using nrfjprog, you use DFU master (such as nRFToolbox ) to flash the application, instead of using KEIL or nrfjprog. The bootloader will take care of writing to that 0x03fc000 address.

However, this may cause some hassle when you are developing application or when you do programming for production. That's why directly writing to nrfjprog.exe --memwr 0x03fc00 --val 0x1 is suggested.

When in development and you want to quickly update the firmware by KEIL without using DFU, you should make sure no CRC is written at address 0x00003FC04, which is the CRC value. In your case it's 0x000000FF (I assume you are using SDK v6.1 with Enum container always int option selected ). YOu shoudl set it to 0x00 to avoid CRC check.