DFU Package overlapping segment

[[email protected]]

I am kind of dumbly following a guide and got as far as collecting the .hex files and attempting to merge a dfu package using the nrf-command-line-tools;

\ota_dfu_util> .\nrf-command-line-tools\bin\mergehex.exe --merge OSL_DFU_Settings.hex OSL_Bootloader.hex s112_nrf52_7.2.0_softdevice.hex OSL_Firmware.hex --output OSL_DFU_Package.hex
Parsing input files.
Merging file "OSL_DFU_Settings.hex" into output.
Merging file "OSL_Bootloader.hex" into output.
Merging file "s112_nrf52_7.2.0_softdevice.hex" into output.
Merging file "OSL_Firmware.hex" into output.

So this error is lost on me. Guidance would be greatly appreciated.

Thanks,

Kevin Lamb

[[email protected]]

<error> app: No bootloader was found
<debug> nrf_sdh: State request: 0x00000000
<debug> nrf_sdh: State change: 0x00000000
<debug> nrf_sdh: State change: 0x00000001
<debug> nrf_sdh_ble: RAM starts at 0x20002EA0
<info> app: device reset

FLASH_PH_START=0x0
FLASH_PH_SIZE=0x30000
RAM_PH_START=0x20000000
RAM_PH_SIZE=0x6000
FLASH_START=0x19000
FLASH_SIZE=0x17000
RAM_START=0x20002EA0
RAM_SIZE=0x3160

[Vidar Berg]

Hello Kevin,

Sorry, but I don't see any errors in the 'mergehex.exe' output you posted. Did you mean to post something else? Also, which bootloader project did you use? 

[email protected] said:

<error> app: No bootloader was found

Do you see this after programming the merged 'OSL_DFU_Package.hex' file to your board? Either way, please read out the UICR register at 0x10001014. This register should contain the start address of the bootloader if it was correctly programmed.

Reading the UICR register with nrfjprog.exe

$ nrfjprog --memrd 0x10001014

Best regards,

Vidar

[Vidar Berg]

No worries. Thank you for providing the additional context.

[email protected] said:

secure_bootloader example (with some modifications for nrf52811).

Which specific project configuration did you use? Projects with 'pca10056e' in their names already have the correct linker and startup files for the nRF52811. The only change required for these projects to run on a 52811 is described here: Transferring the project to nRF52811 hardware.

[email protected] said:

I'm not sure where the bootloader starts but it looks like it was complaining about address 0x00102014.

It appears that merge is printing the address as a decimal value, so the actual address is really 0x19000, not 0x00102014. However, I'm not sure which of the hex files have overlapping data at this address. As a test, maybe try to merge only the OSL_Bootloader.hex with OSL_Firmware.hex to see if you get the same error. 

Edit: I see the problem now: it is the bootloader image that overlaps with the application. The bootloader is supposed to be placed at the end of the flash, as illustrated here: Memory layout.

Please try to build and program the project in /examples/dfu/secure_bootloader/pca10056e_s112_ble_debug and see if it will run on your board. I also recommend you take a look at the  Getting started with Nordic's Secure DFU bootloader, a step by step guide if you have not already.

[[email protected]]

Okay I see the placement differences. Thanks.

I changed things to use /examples/dfu/secure_bootloader/pca10056e_s112_ble_debug

It seems to generate a error after building;

cannot find ../../../../../external/micro-ecc/nrf52nf_armgcc/armgcc/micro_ecc_lib_nrf52.a: No such file or directory

I think the disconnect for me is in step B1a. Compile the uECC library of the guide. I assume this process generates the micro_ecc_lib_nrf52.a file? But I cannot seem to have it make for me via PowerShell. I tried Makefile since that seems to be the name of the file in the folder. Still nothing. Thoughts?

Thanks,
Kevin

[Vidar Berg]

Hi, 

Yes, you need to run the Makefile to build the uECC library (micro_ecc_lib_nrf52.a), and it sounds like you were on the right track.

To build Makefile projects in the SDK, you need to have GNU Make installed and available in PATH, in addition to the GNU ARM Embedded toolchain.

Steps to build uECC

1. Download the GCC toolchain at https://developer.arm.com/downloads/-/gnu-rm/9-2020-q2-update and run the installer. Then, ensure that the 'GNU_INSTALL_ROOT' path in /nRF5_SDK_17.1.0_ddde560/components/toolchain/gcc/Makefile.windows corresponds with your installation directory.

2. Download a version of GNU Make (make.exe) and add the location of this executable to the PATH so that it can be called from the terminal. I've been using the GNU Make version bundled with this package: https://github.com/xpack-dev-tools/windows-build-tools-xpack/releases/. You can run 'make --version' from powershell afterwards to check that it is working. 

3. From the terminal, run the build_all.bat script in /nRF5_SDK_17.1.0_ddde560/external/micro-ecc to fetch uECC source code from github and build all variants of the uECC library.

[[email protected]]

Hey Vidar

I ran the gcc-arm-none-eabi-9-2020-q2-update-win32.exe and it looks like it autopopulated this all, but chime in if you see something wrong please;

1) 

2)

3) Then these errors;

Sorry this windows scripting stuff isn't my strong suit, so definitely appreciate you helping me work through it. 

Thanks,

Kevin Lamb

[Vidar Berg]

Hi Kevin, 

It looks like you are almost there. The problem now is that the script fails to run because make.exe is not found in PATH. The second picture you posted shows that you have added the path to the toolchain, but not the path to GNU Make.

Best regards,

Vidar

[[email protected]]

I'm not really sure why it didn't take the enviroment path but the following fixed it;

PS C:\SDK\nRF5_SDK_17.1.0_ddde560\external\micro-ecc> $env:Path += ";C:\Program Files (x86)\xpack-windows-build-tools-4.4.1-2\bin"
PS C:\SDK\nRF5_SDK_17.1.0_ddde560\external\micro-ecc> .\build_all.bat