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

[cor10]

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());

[Amanda Hsieh]

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

[cor10]

I have looked at that post, which references this post. The post you shared has a solution for nrf52833 chips, so I stuck to the post that I just linked.

I use both the SEGGER Embedded Studio Build & Debug method and the make/Makfile/nrfjprog CLI method of flashing code onto my custom device. As such, Im not sure which MDK version to download at this website. I ended up downloading the most recent GCC version, and replaced the previous mdk/ directory in the nrf-sdk with this new downloaded mdk/ directory. I then ran 'nrfjprog --recover' and then ran my flashing script (the one from above that uses Make). Everything compiles and flashes fine. But when I open the SEGGER Embedded Studio IDE and click Target>Connect, I get this same Pop-up message from the CTRL-AP every single time. The only way I can connect to the device is by running that ERASE ALL. Am I using this new mdk/ correctly? What else can I try?

EDIT: All the stuff below is WRONG. I performed all of these steps after attempting to flash my SoftDevice/Bootloader/Application/Settings, WITHOUT having called 'nrfjprog --reset'. Now, when I make sure to run the reset command after the programming, I am back to the very beginning of this issue, which is: I cannot connect to the SEGGER Debugger without the CTRL-AP requiring that I ERASE ALL, and this erases all of my firmware I just flashed. So I get the "Bootloader Not Found" error again :( ...I did not think it would be this tough to transition from s132 to s140

==========================================================================

==========================================================================

I was able to perform Step 3: CTRL-AP ERASEALL from that post, and this seemed to grant me access into the device so I can debug. However, I still get an ERROR with the value 0x4 like I originally experienced. But, one good thing is that this error is no longer thrown by this function:

APP_ERROR_CHECK(ble_dfu_buttonless_async_svci_init());

Now that I can debug, I have tracked the issue to my ble_init() code. Specifically, in the file nrf_sdh_ble.c, my error arises in the function nrf_sdh_ble_enable():

ret_code_t nrf_sdh_ble_enable(uint32_t * const p_app_ram_start)
{
    // Start of RAM, obtained from linker symbol.
    uint32_t const app_ram_start_link = *p_app_ram_start;

    ret_code_t ret_code = sd_ble_enable(p_app_ram_start);
    if (*p_app_ram_start > app_ram_start_link)
    {
        NRF_LOG_WARNING("Insufficient RAM allocated for the SoftDevice.");

        NRF_LOG_WARNING("Change the RAM start location from 0x%x to 0x%x.",
                        app_ram_start_link, *p_app_ram_start);
        NRF_LOG_WARNING("Maximum RAM size for application is 0x%x.",
                        ram_end_address_get() - (*p_app_ram_start));
    }
    else
    {
        NRF_LOG_DEBUG("RAM starts at 0x%x", app_ram_start_link);
        if (*p_app_ram_start != app_ram_start_link)
        {
            NRF_LOG_DEBUG("RAM start location can be adjusted to 0x%x.", *p_app_ram_start);

            NRF_LOG_DEBUG("RAM size for application can be adjusted to 0x%x.",
                          ram_end_address_get() - (*p_app_ram_start));
        }
    }

    if (ret_code == NRF_SUCCESS)
    {
        m_stack_is_enabled = true;
    }
    else
    {
        NRF_LOG_ERROR("sd_ble_enable() returned %s.", nrf_strerror_get(ret_code));
    }

    return ret_code;
}

In my case, there are two issues.

First, the ret_code value from sd_ble_enable(p_app_ram_start) is 0x4. This ERROR has come up before, and looking in ble.h, I can see that this is NRF ERROR NO MEM.

Second, the first if-case in this function is TRUE, which means I should update my RAM start location. However, when I update the RAM start location to where it says in the code, I can no longer build my project because it says there is insufficient RAM space:

This is strange because all this same code runs perfectly and fits perfectly within our previous nRF52832 device, and the nRF52840 has more space, so what could be causing this??

Either way, I revert the RAM start to where it was previously. This builds and runs, but again, fails on the sd_ble_enable() function call with NRF ERROR NO MEM.

What should I do now to get this code to run?

[Amanda Hsieh]

Hi, 

cor10 said:

The only way I can connect to the device is by running that ERASE ALL. Am I using this new mdk/ correctly? What else can I try?

I add the disable function as that post I provided in the previous link into the bootloader, and it can disable the approtect and attach debugger without asking the erase. Can you try it?

Once you program the images, you can run "nrfjprog --memrd 0x10001208" to check the value of APPROTECT register at 0x10001208. Value 0x5a means the DK is unlocked, then the segger would not ask to erase the kit to attach.   

cor10 said:

First, the ret_code value from sd_ble_enable(p_app_ram_start) is 0x4. This ERROR has come up before, and looking in ble.h, I can see that this is NRF ERROR NO MEM.

Second, the first if-case in this function is TRUE, which means I should update my RAM start location. However, when I update the RAM start location to where it says in the code, I can no longer build my project because it says there is insufficient RAM space:

What are the SD version and the ram start address in this situation? What is the debug log? It should give enough info to guide you to modify the ram start address.

-Amanda

[cor10]

Hi Amanda,

I add the disable function as that post I provided in the previous link into the bootloader, and it can disable the approtect and attach debugger without asking the erase. Can you try it?

I downloaded the most recent MDK version. This new MDK has the exact same file 'system_nrf52_approtect.h' as the one in the link you shared. Are you suggesting I edit this file and remove the if-case that checks to see if defined(ENABLE_APPROTECT)? This way APPROTECT will never be used, is that correct?

Once you program the images, you can run "nrfjprog --memrd 0x10001208" to check the value of APPROTECT register at 0x10001208. Value 0x5a means the DK is unlocked, then the segger would not ask to erase the kit to attach.  

I have done this multiple times, but it doesnt matter. I check the value and it shows 0x5A after successfully programming all the images. So it seems like it will work. But then when I run the 'nrfjprog --reset' command, this APPROTECT seems to get re-enabled, because when I then try and connect the DK to the SEGGER IDE, the same pop-up message appears saying that "CTRL-AP indicates that the device is secured", and the only way I can actually connect is if I accept the pop-up message and ERASE everything....which brings me back to the 'No Bootloader Found' error.

The issue with the RAM start adress doesnt matter that much (please see my EDIT comment above), because I only got to that point in the debugging process after I forgot to run the 'nrfjprog --reset' command (after performing the nrfjprog flash programming commands to write the SoftDevice/Bootloader/App/Settings). I believe it is necessary to run the 'nrfjprog --reset' command before the DK board can actually run the code, right?

What are the SD version and the ram start address in this situation? What is the debug log? It should give enough info to guide you to modify the ram start address.

SoftDevice: Version 16.0.0
RAM start address, originally from my s132 version of the project: 0x20002270
Suggested RAM start address from the debug log:  0x2003FFCC
The debug output definitely gave me enough information to modify the RAM start address. Im not sure if you were able to read my entire last post, but even with this information, when I try to modify the RAM start address, I can no longer BUILD the project, because it says there is insufficient RAM space (please see attached screenshot from my last response).
But this is important: This RAM start issue is not my problem. Right now I still cant even connect to the DK if I run the 'nrfjprog --reset' command. What do you suggest I try now? Thank you so much for your time.

[Amanda Hsieh]

Hi,

cor10 said:

Are you suggesting I edit this file and remove the if-case that checks to see if defined(ENABLE_APPROTECT)? This way APPROTECT will never be used, is that correct?

No, I suggest you add the disable function to the secure_bootloader as that post. 

cor10 said:

I believe it is necessary to run the 'nrfjprog --reset' command before the DK board can actually run the code, right?

Yes. I think that because the bootloader doesn't have the disable function, after 'nrfjprog --reset' the DK gets locked again. You can read the value at 0x10001208 to check.  

Can you try this bootloader 5556.secure_bootloader_ble_s140_pca10056_debug.hex with the disable protect function? I added the function according to that post. 

To build the diable protection, you might need to update MDK for SDK16.0.0, but don't modify the content of the files. 

Here is the test file 287845.7z for nRF52840DK. You can run the bat file to run the image and attach the segger. 

-Amanda