This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

nRF52 app plus bootloader

We're working on getting our nRF52 app working with buttonless OTA updates and the bootloader. OTA works fine with the example bootloader, but when we extend our application to include the bootloader (as described here: infocenter.nordicsemi.com/index.jsp, the app or anything that we can tell never starts properly. It's as if the device is just sitting there.

I suspect our problem is with the packaging of the the hex file. There are a few posts about using mergehex to update the hex file with to apply proper bootloader settings. I've found a few different hex files to merge in various posts which should allow our app to start on power up or reset, but I believe they are specific to the nRF51. Don't know if that makes a difference, but given I've found at least two different ones, and neither works, makes me thinks this could be the problem.

Can anyone provide a proper hex file for the nRF52 dev kit that will allow us to add the bootloader to our app/hex file and have the app properly start on hard reset? Or is there a specific example app in a later version of the SDK that we haven't seen that has a buttonless OTA implemented and working for the nRF52?

We are using nRF52 SDK 0.9.2, with softdevice s132 1.0.0-3 alpha, on pca10040 version of the dev kit. Our app is based on the ble_app_hrs in the SDK. Keil uVision with various jlink tools.

Any help or pointers are appreciated.

Thanks Ed

  • Yes, the application runs fine if I don't try to extend with DFU support. The example code also runs fine, can do an OTA with no problem - the firmware is properly downloaded and the app restarts with the downloaded code with no problem. I've successfully done this with a downloaded image of our own code using the dfu boot loader example.

    I was seeing the same problem when I merge the bootloader with the mergehex command in the first line of my script.

    But I was seeing some other strange behavior with our dev system yesterday (some sort of weird JLink logging behavior on our non-OTA/bootloader version of the code), I'm going to switch systems later today, and will retry everything. I'll let you know what I find, thanks for your help so far.

    Just for reference, is either one of the app_valid_setting_apply.hex files that I used correct? Is one preferred over the other?

    Thanks Ed

  • I recommend setting the BANK_VALID_APP flag in the bootloader code instead of merging in a spearate hex file. You just have to alter one line in in bootloader_settings.c from

    uint8_t  m_boot_settings[CODE_PAGE_SIZE]    __attribute__((at(BOOTLOADER_SETTINGS_ADDRESS))) __attribute__((used));   
    

    to the following

    uint8_t  m_boot_settings[CODE_PAGE_SIZE]    __attribute__((at(BOOTLOADER_SETTINGS_ADDRESS))) __attribute__((used)) = {BANK_VALID_APP};
    
  • Thanks Bjorn, I've made the code change in bootloader_settings.c, getting a couple linker errors about LR_IROM1 size exceeding limits. I'm in meetings all day, I'll troubleshoot those problems later today.

  • I've not been able to find any definitive documentation on setting the IROM1/2 settings to eliminate the linker errors. I need 0x50E0 space according to the linker:

    Load region LR_IROM1 size 20704 Execution region ER_IROM1 20480

    If I expand IROM1 by this amount, nrfprog complains about invalid addresses, I could not find an nRF52 version of this post:

    devzone.nordicsemi.com/.../

    but playing around with various values for IROM1/2 start and size did not produce anything that works.

    If I need a total of 0x50E0 bytes can you tell me the proper IROM1/2 settings, assuming that is indeed my problem.

    Thanks Ed

  • Bjorn or anyone else. Any ideas or suggestions about the linking errors? I can not seem to find the proper settings for the ROM load regions as mentioned above.

    Thanks Ed

Related