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

Hi, 

Seem you are programming s132_nrf52_7.0.1_softdevice.hex and nrf52832_xxaa_s132.hex to nRF52840DK. For nRF52840, you use --family NRF52840 to generate the setting. 

To use the new version of nRF52840DK, you have to run "nrfjprog --recover" to disable the approtect. See this blog. 

Regards,
Amanda

That makes complete sense, thanks. Do you know why our previous nRF52840 DK is able to run this nRF52832 code without ERROR? I feel like I would have been able to encounter/resolve this bug much sooner if the first DK board worked in the same way as this new one...Im curious to hear your thoughts.

Also, I did what you suggested. I made sure to refer to the correct s140 SoftDevice for the nRF52840. The softdevice flashes perfectly to the DK board, as before. I am simplifying my script for step-by-step debugging, and all I try to do after flashing the softdevice is to flash the bootloader. I made edits to the script to also reference the correct bootloader, as you can see here:

#! /bin/bash

# nRF52840

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

softdevice='../nrf-sdk/components/softdevice/s140/hex/s140_nrf52_7.0.1_softdevice.hex'

make -C "$boot_make"

nrfjprog -e
nrfjprog --program "$softdevice" --verify
nrfjprog --program "$boot" --verify --log .

nrfjprog --reset

Unfortunately, these new changes dont seem to help. I am still encountering the same ERROR from the nrfjprog command line tool, which you can see here:

Lastly, I have included the log output from this failed flash for your reference. What could be causing this error? What should I try to debug this issue? Thank you so much for your help with this.

Hi, 

Seems the error happened while programming nrf52840_xxaa_s140.hex. Could you check the flash address or upload the image? Here is the Memory layout. 

-Amanda

Im not sure how to check the flash address, but here is the .hex file created as a result of running my script (specifically the call to make)

Would you mind pointing me in the direction of resources where I can learn how to check high-level bootloader info like the flash address, etc?

EDIT: I dug around and found a file called flash_placement.xml in the /dfu/secure_bootloader/pca10056_s140_ble/ses/ directory. Here are some relevant sections:

  <MemorySegment name="bootloader_settings_page" start="0x000FF000" size="0x1000">
    <ProgramSection alignment="4" keep="Yes" load="No" name=".bootloader_settings_page" address_symbol="__start_bootloader_settings_page" end_symbol="__stop_bootloader_settings_page" start = "0x000FF000" size="0x1000" />
  </MemorySegment>
  <MemorySegment name="mbr_params_page" start="0x000FE000" size="0x1000">
    <ProgramSection alignment="4" keep="Yes" load="No" name=".mbr_params_page" address_symbol="__start_mbr_params_page" end_symbol="__stop_mbr_params_page" start = "0x000FE000" size="0x1000" />
  </MemorySegment>
  <MemorySegment name="uicr_bootloader_start_address" start="0x10001014" size="0x4">
    <ProgramSection alignment="4" keep="Yes" load="Yes" name=".uicr_bootloader_start_address" address_symbol="__start_uicr_bootloader_start_address" end_symbol="__stop_uicr_bootloader_start_address" start = "0x10001014" size="0x4" />
  </MemorySegment>
  <MemorySegment name="uicr_mbr_params_page" start="0x10001018" size="0x4">
    <ProgramSection alignment="4" keep="Yes" load="Yes" name=".uicr_mbr_params_page" address_symbol="__start_uicr_mbr_params_page" end_symbol="__stop_uicr_mbr_params_page" start = "0x10001018" size="0x4" />
  </MemorySegment>

Is my issue coming from the "uicr_bootloader_start_address" parameter in this file, which is "0x10001014" instead of something more close to the Memory Layout table you shared with me, which says we should expect the start address to be "0x000F8000"?

Hi, 

What is the DK HW version? See the white sticker on the DK.

What is the nrfjprog version (nrfjprog -v)? Could you try the latest version of the nRF Command Line Tools?

-Amanda

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.

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?

Hi, 

cor10 said:

Could it be erasing all of the SoftDevice/Bootloader/AppImage/Settings that I just flashed, and this is why it complains about "No Bootloader"?

Seems that might cause the issue. Can you try this post?

-Amanda