• State Verified Answer
  • Replies 7 replies
  • Subscribers 73 subscribers
  • Views 6517 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 107500
Options
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

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

  • 0

    According to this thread, GATT Error (0x83) could be due to bonding and/or Android version problem. I tried to connect to my custom board with NRF51822QFAA without any bonding and with a Samsung phone with Android version 5.0, but still not able to complete service discovery.

  • 0

    Update: I was able to switch from normal operation mode to bootloader mode for application firmware upgrade. The issue was that DFU service initialization was returning NRF_ERROR_NO_MEM. I removed some of the stale and unnecessary code such as dm_ble_evt_handler(p_ble_evt); from ble_stack_init() routine in the application, etc. for my setup(SDK v6.1.0, SD v7.1.0) and it worked. Summary: Now I'm able to put NRF51822QFAA into DFU mode, with an existing application and do application firmware upgrade using Nordic MCP for Android.

  • 0

    I've now another issue. I'm now not able to boot from the application f/w which is flashed using normal method (J-link and KEIL). Please see the steps below for complete information:

    • Erase all using nrfjprog.exe

    • Flash SD v7.1.0 using nRFStudio Go.

    • Flash Bootloader using Keil, J-link and nrfjprog.exe

    • Observe that the Device now starts advertising as "Dfu Targ"

    • Flash application using nRF Toolbox

    • Observe that the device now starts advertising as "test_01"

    • Read memory location 0x03fc00 using nrfjprog.exe

      0x0003FC00: 772B0001 000000FF |..+w....|

    • Flash application f/w using Keil, J-link and without any external utility (nrfjprog.exe)

    Expection:

    New application f/w (say test_02) should show up

    Actual result:

    Device stays in bootloader mode, i.e. starts advertising as "Dfu Targ"

  • 0

    Update: After flashing the new application f/w using, the usual method of KEIL and J-link (as mentioned in my previous comment), I once again wrote 0x1 at the address 0x03FC00 using nrfjprog.exe and did a soft reset, i.e.

    $ nrfjprog.exe --memwr 0x03fc00 --val 0x1

    $ nrfjprog.exe --reset

    This time, the bootloader seemed to have found the new application f/w and my custom now started advertising as test_02(as expected). This method is okay, but Is there an alternative way to achieve this, i.e. by doing some changes in bootloader and/or application code ? Basically, I would like to be able to upgrade application f/w using both usual and DFU-OTA methods.

    (Note that, application f/w upgrade with Nordic MCU or nRF Toolbox for Android does not require me to write anything at the address (0x03FC00) for a successful boot from new application firmware after upgrade)

  • 0

    @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.

Related
Terms of service