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

Easy development with BL + SD + APP

raphael_gsa

Hi all,

I'm developing a buttonless DFU based application using the SDK v15.3
Following the documentation was pretty easy and I'm now able to run the app_ble_buttonless_dfu example with a secured ble bootloader.

I'm using SES and a PCA10040 DK for my developments. The issue is that when I'm developing, each time I want to test/debug my application code, I have to :
- Compile the application code using SES
- Create a new Bootloader Setting File accordingly to the new application hex file
- Merge the Bootloader Setting File and the application hex file
- Erase the SDK
- Flash the SD, the newly merged hex file and the Bootloader to the DK
- And finally, test and debug with SES

Is there a way to quickly/easily debug and develop like I'm used to do it for any non-bootloader related application ?

Thanks for any help :-)

Parents
  • +1

    Hi,

    The problem when building and testing/debugging a modified application when you have a bootloader is that the bootloader does a CRC check of the application at startup, and if the CRC does not match, the bootloader enters DFU mode instead of starting the application. There are a few ways to handle this problem:

    1. After building and programming the updated application, use nrfutil to generate a new setting page providing the new application .hex, and then program it using nrfjprog with the --sectorerase option. This will make the settings page contain the correct CRC and the bootloader will start the application.

    2. A simpler option is to just modify the bootloader so that it does not do a CRC check during startup. Then you can always add back the CRC check before going to production. This can be done in several ways, for instance by modifying the crc_on_valid_app_required() implementation in <SDK 15.3>\components\libraries\bootloader\nrf_bootloader.c like this:

    static bool crc_on_valid_app_required(void)
{
    return false;
}

Reply
  • +1

    Hi,

    The problem when building and testing/debugging a modified application when you have a bootloader is that the bootloader does a CRC check of the application at startup, and if the CRC does not match, the bootloader enters DFU mode instead of starting the application. There are a few ways to handle this problem:

    1. After building and programming the updated application, use nrfutil to generate a new setting page providing the new application .hex, and then program it using nrfjprog with the --sectorerase option. This will make the settings page contain the correct CRC and the bootloader will start the application.

    2. A simpler option is to just modify the bootloader so that it does not do a CRC check during startup. Then you can always add back the CRC check before going to production. This can be done in several ways, for instance by modifying the crc_on_valid_app_required() implementation in <SDK 15.3>\components\libraries\bootloader\nrf_bootloader.c like this:

    static bool crc_on_valid_app_required(void)
{
    return false;
}

Children
Related
Terms of service