Writing programs using nRF Connect Programmer

[komuro]

I wrote a program for nRF51822 and compiled it with keil.
The app, boot, and sdk are combined and written to the chip.
However, if I write using nRF Connect Programmer, it works without boot.
Why does it work without boot when writing with nRF Connect Programmer?
*When writing without boot using a tool other than nRF Connect Programmer, it did not work.

[Vidar Berg]

Hello,

Please check if the "Reset and Run" checbox is ticked in your debugger settings.

[komuro]

Thank you for confirming.
In the debugger settings, the "Reset and Run" checkbox was checked.
Is this check related to the fact that it works with nRF Connect Programmer and does not work with tools other than nRF Connect Programmer?

[komuro]

Vidar Berg said:

What other tools do you use for programming?

It was confirmed.
NETIMPRESS AF430 is used for writing.
SWD Adapter AZ442 is also used.

[Vidar Berg]

Ok, so if I've understood this correctly, the device works ok if you don't program the bootloader, right? If so, is it possible that they may still be writing the bootloader address to the UICR @ 0x10001014 even if the bootloader is not present? 

The master boot record will assume that a bootloader is present if this register is set as explained here: Bootloader

[komuro]

Thanks for confirming.

Set "sd_softdevice_vector_table_base_set(NRF_UICR->BOOTLOADERADDR)" in "bootloader_start()" of dfu_app_handler.c.
"bootloader_start()" is not set at startup, but is it called from within the library at startup?
Does "nRF Connect Programmer" work properly unlike "Another Tool" because of the above settings?

[Vidar Berg]

The question is if the "NETIMPRESS" programmer is writing to the NRF_UICR->BOOTLOADERADDR register at 0x10001014 when they are programming the app + sd.

[komuro]

I checked the HEX file.
We have confirmed that the HEX file we wrote sets the boot address (0x0003C000) to 0x10001014.
The following is the setting location.
-----
:02000000041000EA
:0410140000C0030015


In addition, we have additionally confirmed the following
Two patterns of writing (nRFconnect and NETIMPRESS) were performed, and the HEX files were compared by reading each pattern.
As a result of comparison, the following differences were found between nRFconnect and NETIMPRESS.


The following is an excerpt from the read results of nRFconnect.
-----
 :020000041000EA
 :10100000FFFFFFFFFFFFFFFF00FFFFFFFFFFFFFFEF
 :10101000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFE0

The following is an excerpt from the read results of  NETIMPRESS.
-----
 :020000041000EA
 :1010000000800100FFFFFFFF00FFFFFFFFFFFFFF6A
 :10101000FFFFFFFF00C00300FFFFFFFFFFFFFFFF19


Checking the above, I am still back to my initial question.
I see that NETIMPRESS has the boot address set and works.
In nRFconnect, the boot address is not set to 0x10001014.
Why does it work?

[Vidar Berg]

Hi,

The boot address shall only be written when you program the bootloader hex. So the question is why the NETIMPRESS programmer is writing the bootloader start address to 0x10001014 when it's not included in the hex file.

Maybe you have a custom programming scripts that writes this address after loading the hex files (i.e. app+sdk)?

[komuro]

Hi,

As for the HEX file I wrote, the bootloader is implemented and the address of the boot (0x0003C000) is also set to 0x10001014.
Therefore, I believe it is correct that NETIMPRESS works (because the address of boot is written to 0x10001014).

nRFconnect works even without boot. I think this behavior is special, why is this?

[Vidar Berg]

Yes, but the NETIMPRESS programmer should only write to 0x10001014 when it's programming the bootloader.