This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

ERROR: Not valid hex file when flashing code to new DK board

I am using an nRF52840 DK board that I just bought, but have ran into a weird issue that I have never come across when using our old nRF52840 DK. I have a script that I use to first compile my project code, and then flash everything onto my DK board. Here is the code of that script:

#! /bin/bash

## Compile bootloader and application:
boot_make='../nrf-sdk/examples/dfu/secure_bootloader/pca10040_s132_ble/armgcc/'
boot=${boot_make}_build/nrf52832_xxaa_s132.hex

softdevice='../nrf-sdk/components/softdevice/s132/hex/s132_nrf52_7.0.1_softdevice.hex'

app_make='../nrf-sdk/examples/ble_peripheral/ble_app_technolingus/pca10040/s132/armgcc/'
app=${app_make}_build/nrf52832_xxaa.hex


make -C "$boot_make"
make -C "$app_make"

nrfutil settings generate --family NRF52 --application "$app" --application-version 1 --bootloader-version 1 --bl-settings-version 2 settings.hex

nrfjprog -e
nrfjprog --program "$softdevice" --verify
nrfjprog --program "$boot" --verify --log .
nrfjprog --program "$app" --verify
nrfjprog --program settings.hex --verify

nrfjprog --reset

My code compiles and the hex files are generated as a result of the calls to make -C "$boot_make" and make -C "$app_make". However, when the script finishes programming the softdevice, it complains with ERRORS about the other .hex files I am trying to flash. Here is that output for your reference:

Only moments ago, when running the same code for an older DK (same nRF52840), this script worked fine and everything flashed correctly. I cant figure out why this new DK board causes the programming to fail. What might be causing this new behavior (even though there is no code change)?

I have also attached the log output file from logging the first failing nrfjprog --program command for your reference....if it helps.

The only other thing I have tried is to erase my device from Segger ES (Target > Connect JLink, Target > Erase All), download the secure bootloader ble example, then download my custom application. When I Build and Debug this code, my project always fails at this function, with the same error (NRF ERROR NO MEM "No bootloader found"):

APP_ERROR_CHECK(ble_dfu_buttonless_async_svci_init());


  • Hello Amanda. Thanks for helping with this.

    On the older DK board, here is what the sticker says:

    • PCA10056
    • 1.1.0
    • 2019.25
    • 683638102

    On my most recent DK board:

    • PCA10056
    • 3.0.0
    • 2022.7
    • 1050260108

    My nrfjprog version is:

    • nrfjprog version: 10.12.1
    • JLinkARM.dll version: 7.60a

    The link you shared leads me to a "Page Not Found" error. But I was able to find a link to the nRF Command Line Tools downloads, and see that there is a 10.15.4 version, so I will try that now.

  • Hi, 

    cor10 said:
    The link you shared leads me to a "Page Not Found" error. But I was able to find a link to the nRF Command Line Tools downloads, and see that there is a 10.15.4 version, so I will try that now.

    Sorry for attaching the wrong link. I fix it now. Can the v10.15.4 work?

    -Amanda 

  • Hi Amanda, this v10.15.4 did perform much better. I was finally able to compile and flash everything to the device without any errors being thrown by the 'nrfjprog' command line tool. However, this did not resolve the same error which I refer to in my original post at the top.

    Specifically, this line of code:

    APP_ERROR_CHECK(ble_dfu_buttonless_async_svci_init());

    is still throwing the "No Bootloader Found" error. When I attach the debugger, I can see that this issue is with the Bootloader address. Inside this ble_dfu_buttonless_async_svci_init() function call, there is another function nrf_dfu_svci_vector_table_set():

    uint32_t nrf_dfu_svci_vector_table_set(void)
    {
        uint32_t err_code;
        uint32_t bootloader_addr = BOOTLOADER_ADDRESS;
    
        if (bootloader_addr != 0xFFFFFFFF)
        {
            NRF_LOG_INFO("Setting vector table to bootloader: 0x%08x", bootloader_addr);
            err_code = sd_softdevice_vector_table_base_set(bootloader_addr);
            if (err_code != NRF_SUCCESS)
            {
                NRF_LOG_ERROR("Failed running sd_softdevice_vector_table_base_set");
                return err_code;
            }
    
            return NRF_SUCCESS;
        }
    
        NRF_LOG_ERROR("No bootloader was found");
        return NRF_ERROR_NO_MEM;
    }

    This function checks to see if BOOTLOADER_ADDRESS is equal to 0xFFFFFFFF. In this case, BOOTLOADER_ADDRESS is defined in app_util.h, as:

    #define BOOTLOADER_ADDRESS      ((*(uint32_t *)MBR_BOOTLOADER_ADDR) == 0xFFFFFFFF ? *MBR_UICR_BOOTLOADER_ADDR : *(uint32_t *)MBR_BOOTLOADER_ADDR) 
    /**< The currently configured start address of the bootloader. If 0xFFFFFFFF, no bootloader start address is configured. */
    

    And this depends on the definition of MBR_BOOTLOADER_ADDR in nrf_mbr.h. Here are some relevant definitions from that header:

    /**@brief MBR SVC Base number. */
    #define MBR_SVC_BASE            (0x18)
    
    /**@brief Page size in words. */
    #define MBR_PAGE_SIZE_IN_WORDS  (1024)
    
    /** @brief The size that must be reserved for the MBR when a SoftDevice is written to flash.
    This is the offset where the first byte of the SoftDevice hex file is written. */
    #define MBR_SIZE                (0x1000)
    
    /** @brief Location (in the flash memory) of the bootloader address. */
    #define MBR_BOOTLOADER_ADDR      (0xFF8)
    
    /** @brief Location (in UICR) of the bootloader address. */
    #define MBR_UICR_BOOTLOADER_ADDR (&(NRF_UICR->NRFFW[0]))
    
    /** @brief Location (in the flash memory) of the address of the MBR parameter page. */
    #define MBR_PARAM_PAGE_ADDR      (0xFFC)
    
    /** @brief Location (in UICR) of the address of the MBR parameter page. */
    #define MBR_UICR_PARAM_PAGE_ADDR (&(NRF_UICR->NRFFW[1]))

    One would think that 0xFF8 is not equal to 0xFFFFFFFF....what could be happening here? Why wont the bootloader be recognized? Anything that I can try?

    Many thanks :)

    EDIT: Could it be due to my use of the dfu_secure_bootloader? I am seeing new behavior in the SEGGER Embedded Studio that is telling me my device is secured, and that if I want debugger connection, I must unsecure the device which causes a big ERASE of all flash memory. The only way I can attach the debugger is to accept and unsecure the device, which ERASES things. Could it be erasing all of the SoftDevice/Bootloader/AppImage/Settings that I just flashed, and this is why it complains about "No Bootloader"? This behavior never happened when using the secure dfu bootloader with the other nRF52840 DK and also never with our custom s132 device, so I am confused. Any help is appreciated.

  • Hi, 

    Please try to run "nrfjprog --recover" before programming SD+BL+APP+setting and let me know if this can help or not. Thanks. 

    -Amanda

  • Yes, I already do this every time. If I do not run the recover command before the flash, it will not work. Anything else in mind?

Related