nRF52832 + nrfjprog: need to program twice

[Tamas Selmeci]

Our custom board has an nRF52832. In our custom build system the application HEX and SoftDevice HEX are merged together into a single HEX file, this is achieved by Nordic's mergehex tool. nrfjprog is used to program the device's flash. Here's the command:

nrfjprog \
		-s 269400451 \
		--jdll $(TOOL_DIR)/opt/JLink_Linux/libjlinkarm.so \
		-f NRF52 \
		--clockspeed 4000 \
		--program complete.hex \
		--sectorerase \
		--reset

Executes without a problem. The weird thing is that if I change the source code, recompile the program and issue the command above, the MCU fails to start, but after the second call of this command the MCU starts with the new binary.

It's quite annoying to always burn the same new flash content two times. Have you got any idea what can this be?

Thanks,

[Håkon Alseth]

Hi,

 

 

Executes without a problem. The weird thing is that if I change the source code, recompile the program and issue the command above, the MCU fails to start, but after the second call of this command the MCU starts with the new binary.

It's quite annoying to always burn the same new flash content two times. Have you got any idea what can this be?

I haven't seen this behavior myself, but; I do see that you do not use --verify, so that might be an issue.

What version of nrfjprog / jlink are you using? This can be printed via nrfjprog --version.

 

Kind regards,

Håkon

[Tamas Selmeci]

Thanks for the help.

--verify itself didn't solve the issue, but showed me that every second write of the flash is bad, verify fails. (It appears that --sectorerase may contain bugs).

I've refactored my build script and it now works alright:

	$(TOOL_DIR)/opt/nrfjprog/nrfjprog \
		--jdll $(TOOL_DIR)/opt/JLink_Linux/libjlinkarm.so \
		-f NRF52 \
		--clockspeed 4000 \
		--erasepage 0x00000000-0x0007E000
	
	$(TOOL_DIR)/opt/nrfjprog/nrfjprog \
		--jdll $(TOOL_DIR)/opt/JLink_Linux/libjlinkarm.so \
		-f NRF52 \
		--clockspeed 4000 \
		--program complete.hex \
		--verify \
		--reset

NOTE: the last two pages of the flash are intentionally not erased, because some config is stored there.

[Håkon Alseth]

You can try to reduce the clock speed, and see if this has any impact on the verification process.

In addition, I would recommend checking your nrfjprog version to see if its old.

 

Kind regards,

Håkon

[Tamas Selmeci]

These are my versions:

nrfjprog version: 9.8.1
JLinkARM.dll version: 6.40

[Håkon Alseth]

The newest nrfjprog is v10.6.0, and the jlinkarm is at v6.60. You could try to update and see if this helps the scenario.

 

Cheers,

Håkon