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

[cor10]

Ok, now I understand what you mean about that post you linked. When I clicked it at first, I went to the selected/verified solution of the post, which mentioned downloading the newest MDK version and so I tried that. The disable function you are referring to did not solve the problem for the person who made the post, so I overlooked that.

Now that I understand, I added the disable function to my secure_bootloader solution in the main.c file at the beginning of the main() function, exactly as is suggested in the post you linked (I didnt use your .hex file because I have necessary configs set in the sdk_config.h file). However, this solution does not work for me. I notice that the #if statement appears inactive in my SEGGER IDE, so perhaps it is never run:

Also, let me show you the series of commands I make from my terminal so you can see my situation more clearly:

% nrfjprog --recover                                                                                                                                                                                
Recovering device. This operation might take 30s.                                                                                                                                                                              
Writing image to disable ap protect.                                                                                                                                                                                           
Erasing user code and UICR flash areas.

% nrfjprog --memrd 0x10001208                                                                                                                                                                       
0x10001208: 0000005A                              |Z...|

% nrfjprog --memrd 0x40000558                                                                                                                                                                       
0x40000558: 00000000                              |....|

% ./dfu-bl-settings-nrf52840.sh                                                                                                                                                                     
DONE nrf52840_xxaa_s140                                                                                                                                                                                                        
DONE nrf52840_xxaa                                                                                                                                                                                                             
                                                                                                                                                                                                                               
Note: Generating a DFU settings page with backup page included.                                                                                                                                                                
This is only required for bootloaders from nRF5 SDK 15.1 and newer.                                                                                                                                                            
If you want to skip backup page generation, use --no-backup option.                                                                                                                                                            
                                                                                                                                                                                                                               
Generated Bootloader DFU settings .hex file and stored it in: settings.hex                                                                                                                                                     
                                                                                                                                                                                                                               
Bootloader DFU Settings:                                                                                                                                                                                                       
* File:                     settings.hex                                                                                                                                                                                       
* Family:                   NRF52840                                                                                                                                                                                           
* Start Address:            0x000FF000                                                                                                                                                                                         
* CRC:                      0x4559EA38                                                                                                                                                                                         
* Settings Version:         0x00000002 (2)
* App Version:              0x00000001 (1)
* Bootloader Version:       0x00000001 (1)
* Bank Layout:              0x00000000
* Current Bank:             0x00000000
* Application Size:         0x000114FC (70908 bytes)
* Application CRC:          0x51D124B6
* Bank0 Bank Code:          0x00000001
* Softdevice Size:          0x00000000 (0 bytes)
* Boot Validation CRC:      0x559D0208
* SD Boot Validation Type:  0x00000000 (0)
* App Boot Validation Type: 0x00000001 (1)

Recovering device. This operation might take 30s.
Writing image to disable ap protect.
Erasing user code and UICR flash areas.
Erasing user available code and UICR flash areas.
Applying system reset.                                 
Parsing image file.                                    
Verifying programming.                                 
Verified OK.                                           
Parsing image file.                                    
Verifying programming.                                 
Verified OK.                                           
Parsing image file.                                    
Verifying programming.                                 
Verified OK.                                           
Parsing image file.                                    
Verifying programming.                                 
Verified OK.                                           
Applying system reset.                                 
Run.                                                   

% nrfjprog --memrd 0x10001208   
ERROR: The operation attempted is unavailable due to readback protection in
ERROR: your device. Please use --recover to unlock the device.
NOTE: For additional output, try running again with logging enabled (--log).
NOTE: Any generated log error messages will be displayed.

As you can see above, I first recover the DK and then perform a read operation to check the APPROTECT disable value. It is 0x5A so that seems good. Then I run my flash programming script (shared below for your reference). This flashes the newest secure_bootloader with the disable function added to main as you suggested. Once all the programming finishes, I again attempt to perform a read to check on APPROTECT, but it immediately tells me that I cannot talk to the DK unless I recover it again, aka APPROTECT is not disabled.

Here is my programming script:

#! /bin/bash

## 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'

app_make='../nrf-sdk/examples/ble_peripheral/ble_app_technolingus/pca10056/s140/armgcc/'
app=${app_make}_build/nrf52840_xxaa.hex


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

nrfutil settings generate --family NRF52840 --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

Regardless of these efforts, I was able to find a (hacky) solution!!! If I write 0x5A to the APPROTECT.DISABLE register (0x40000558), I am able to access the DK device even after running the 'nrfjprog --reset' command. I also make sure that the value of UICR.APPROTECT register (0x10001208) is 0x5A.

% nrfjprog --memrd 0x10001208                                                                                                                                                                       
0x10001208: 0000005A                              |Z...|

% nrfjprog --memrd 0x40000558                                                                                                                                                                       
0x40000558: 00000000                              |....|

% nrfjprog --memwr 0x40000558 --val 0x5a                                                                                                                                                            
Parsing parameters.                                                                                                                                                                                                            
Writing.

% nrfjprog --memrd 0x40000558                                                                                                                                                                       
0x40000558: 0000005A                              |Z...|

% ./dfu-bl-settings-nrf52840.sh         
DONE nrf52840_xxaa_s140
DONE nrf52840_xxaa

Note: Generating a DFU settings page with backup page included.
This is only required for bootloaders from nRF5 SDK 15.1 and newer.
If you want to skip backup page generation, use --no-backup option.

Generated Bootloader DFU settings .hex file and stored it in: settings.hex

Bootloader DFU Settings:
* File:                     settings.hex
* Family:                   NRF52840
* Start Address:            0x000FF000
* CRC:                      0x4559EA38
* Settings Version:         0x00000002 (2)
* App Version:              0x00000001 (1)
* Bootloader Version:       0x00000001 (1)
* Bank Layout:              0x00000000
* Current Bank:             0x00000000
* Application Size:         0x000114FC (70908 bytes)
* Application CRC:          0x51D124B6
* Bank0 Bank Code:          0x00000001
* Softdevice Size:          0x00000000 (0 bytes)
* Boot Validation CRC:      0x559D0208
* SD Boot Validation Type:  0x00000000 (0)
* App Boot Validation Type: 0x00000001 (1)

Recovering device. This operation might take 30s.
Writing image to disable ap protect.
Erasing user code and UICR flash areas.
Erasing user available code and UICR flash areas.
Applying system reset.
Parsing image file.
Verifying programming.
Verified OK.
Parsing image file.
Verifying programming.
Verified OK.
Parsing image file.
Verifying programming.
Verified OK.
Parsing image file.
Verifying programming.
Verified OK.
Applying system reset.
Run.

% nrfjprog --memrd 0x10001208           
0x10001208: 0000005A                              |Z...|

% nrfjprog --memrd 0x40000558  
0x40000558: 0000005A                              |Z...|

So, I can now successfully connect to the SEGGER IDE for debugging and my code is finally running! HOWEVER, with this solution, I notice that whenever my DK device is powered OFF and then back ON again, the DK goes back into the APPROTECT state and locks me out. So if I turn my device OFF, I can no longer connect to the SEGGER IDE for debugging, and I have to recover the device and run my programming script again. Even though I do not re-write to the APPROTECT.DISABLE register, I notice that the value is still 0x5A after erasing everything and re-programming. Do you know why this happens when the device is turned OFF? Is there a way I can avoid this behavior after power OFF? Or is there a more elegant solution?

Thank you :)

[Amanda Hsieh]

Hi, 

You can add "APPROTECT_HW_DISABLE" to Project -> Preprocessor -> Processor Definitions to enable the tag. Once programming the bootloader with  APPROTECT_HW_DISABLE, it will write the 

cor10 said:

Even though I do not re-write to the APPROTECT.DISABLE register, I notice that the value is still 0x5A after erasing everything and re-programming. Do you know why this happens when the device is turned OFF? Is there a way I can avoid this behavior after power OFF? Or is there a more elegant solution?

Not sure why caused that. 

cor10 said:

I notice that whenever my DK device is powered OFF and then back ON again, the DK goes back into the APPROTECT state and locks me out. So if I turn my device OFF, I can no longer connect to the SEGGER IDE for debugging, and I have to recover the device and run my programming script again. Even though I do not re-write to the APPROTECT.DISABLE register, I notice that the value is still 0x5A after erasing everything and re-programming.

What is the value of 0x10001208 after powered OFF and ON? Guess the value at UICR.APPROTECT register is written by your image. It should use the bootloader with APPROTECT_HW_DISABLE that can write  UICR.APPROTECT register (0x10001208) to 0x5A.

-Amanda

[cor10]

Amanda, thank you for sticking with me through this battle. With that Preprocessor Definition, the approtect_hw_disable() #if-statement runs properly and allows access to the debugger every time now.

Also, I figure that the value of the APPROTECT.DISABLE register seems to be RESET to 0x0 after a power OFF/ON, which is why I was seeing the APPROTECT come up again. But now with the new working secure_bootloader, the device disables APPROTECT functionality even after being turned OFF/ON.

Thank you, I have learned a lot!

Cheers,

Corten