• State Suggested Answer
  • Replies 3 replies
  • Answers 1 answer
  • Subscribers 73 subscribers
  • Views 1398 views
  • Users 0 members are here
Attachments (1) Download All
Nordic Case Info
  • Case ID: 200935
Options
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

DFU problems during migration from SDK 13 to SDK 14

Massimo Pilia

Hi,

related to a previous question I posted, 

Application does not start beside DFU bootloader
Verified Answer
Hy everybody, I'm trying to implement DFU bootloader in our custom board, starting from the "bootloader_secure_example", where I just changed leds and button pins in order to adapt them to our board…
By in Nordic DevZone > Nordic Q&A
12 replies
Latest by
, we are migrating from nRF5_SDK_13.1.0_7ca7556 to nRF5_SDK_14.2.0_17b948a.

Now we have some problems with the bootloader again.

We can flash the application but then the board remains in bootloader mode, advertising as DfuTarg.

We also tried to perform a DFU with the same result.

It seams the bootloader doesn't validate the application. But how can we debug it? If we use the macro NRF_DEBUG_ENABLE the compiler returns a no_space error.

The only things we changed are:

  1. the SoftDevice requirements (from 0x98 to 0x9D) in the command used to generate the DFU packet;
  2. the macro  NRF_SD_BLE_API_VERSION (from 4 to 5) in the keil option for target.

Is there any other change we have to do during migration?

Thanks a lot

Massimo

Parents
  • 0

    Hi

    We can flash the application but then the board remains in bootloader mode, advertising as DfuTarg.

    This is because flashing the app does not set it as valid in the bootloader setting page. When the bootloader starts it will determine if it has a valid app based on the state of the settings page and a CRC check verifying the integrity of the application. You need to, as you say you did, perform a DFU to get the app into the system. Performing the DFU like you did should have worked if everything was working as intended, so we need to figure out the problem.

    But how can we debug it? If we use the macro NRF_DEBUG_ENABLE the compiler returns a no_space error.

    First a clarification, you can run a debugger like the one in Segger Embedded studio, GDB, Segger Ozone, or other without setting this macro. This macro is intended for when you are adding logging capabilities and removing some security checks from the bootloader to simplify development of bootloader features. You may not need to set this macro at all if you just use a debugger instead of depending on logging.

    The problem you have found is that the bootloader is size limited. If you look into the SDK you will see that the there is a pca100XX and pca100XX_debug target for each supported nRF5 device. The debug project has the size settings and logging capabilities that you may want. Have a look at how this is done there and add it to your system if you want to have logging, but remember this is just a tool for development and not intended for production code.

    Is there any other change we have to do during migration?

    Unfortunately, there are quite a few things you need to change. The new SoftDevice comes with a new API and you will have to update the SoftDevice calls that have been changed. I have attached the migration guide for migration from API4 to API5 (This is available as part of the SoftDevice S132v5.0.0 release zip). In addition, there is a bug in SDK 13.1.0 which requires a workaround in the new bootloader when you upgrade devices already shipped. If you do not have old devices which have to be updated over the air and you are just trying to upgrade to the newest SoftDevice before delivery you don't have to worry about this one.

    My general advice is to consider how many custom changes you have made to the SDK 13.1.0 Secure DFU bootloader and consider what is the simples solution for you:

    • Follow the migration guide and get your current bootloader up and running on the new SoftDevice. There are probably some other minor changes you have to do like changing NRF_SD_BLE_API_VERSION. This solution will require you to test your own solution well to ensure that there are no bugs introduced in the porting.
    • Run a diff between your current bootloader and the bootloader in SDK 13.1.0 and apply the same changes to the bootloader in SDK 14.2.0. If there are many complex bootloader changes this may be hard to do without introducing new bugs that may be hard to debug. Otherwise, this is the solution I would use.

    Best regards,
    Rune Holmgren

    s132_nrf52_5.0.0_migration-document.pdf

Reply
  • 0

    Hi

    We can flash the application but then the board remains in bootloader mode, advertising as DfuTarg.

    This is because flashing the app does not set it as valid in the bootloader setting page. When the bootloader starts it will determine if it has a valid app based on the state of the settings page and a CRC check verifying the integrity of the application. You need to, as you say you did, perform a DFU to get the app into the system. Performing the DFU like you did should have worked if everything was working as intended, so we need to figure out the problem.

    But how can we debug it? If we use the macro NRF_DEBUG_ENABLE the compiler returns a no_space error.

    First a clarification, you can run a debugger like the one in Segger Embedded studio, GDB, Segger Ozone, or other without setting this macro. This macro is intended for when you are adding logging capabilities and removing some security checks from the bootloader to simplify development of bootloader features. You may not need to set this macro at all if you just use a debugger instead of depending on logging.

    The problem you have found is that the bootloader is size limited. If you look into the SDK you will see that the there is a pca100XX and pca100XX_debug target for each supported nRF5 device. The debug project has the size settings and logging capabilities that you may want. Have a look at how this is done there and add it to your system if you want to have logging, but remember this is just a tool for development and not intended for production code.

    Is there any other change we have to do during migration?

    Unfortunately, there are quite a few things you need to change. The new SoftDevice comes with a new API and you will have to update the SoftDevice calls that have been changed. I have attached the migration guide for migration from API4 to API5 (This is available as part of the SoftDevice S132v5.0.0 release zip). In addition, there is a bug in SDK 13.1.0 which requires a workaround in the new bootloader when you upgrade devices already shipped. If you do not have old devices which have to be updated over the air and you are just trying to upgrade to the newest SoftDevice before delivery you don't have to worry about this one.

    My general advice is to consider how many custom changes you have made to the SDK 13.1.0 Secure DFU bootloader and consider what is the simples solution for you:

    • Follow the migration guide and get your current bootloader up and running on the new SoftDevice. There are probably some other minor changes you have to do like changing NRF_SD_BLE_API_VERSION. This solution will require you to test your own solution well to ensure that there are no bugs introduced in the porting.
    • Run a diff between your current bootloader and the bootloader in SDK 13.1.0 and apply the same changes to the bootloader in SDK 14.2.0. If there are many complex bootloader changes this may be hard to do without introducing new bugs that may be hard to debug. Otherwise, this is the solution I would use.

    Best regards,
    Rune Holmgren

    s132_nrf52_5.0.0_migration-document.pdf

Children
Related
Terms of service