Problem writing to nrf52840

[Boggibill]

I am using the following chip: NRF52840-QIAA-R

boggi@getshop-boggi:~/....$ nrfjprog --program /home/boggi/..../build_1/zephyr/zephyr.hex --sectoranduicrerase --verify -f NRF52 --snr 1050385234 --log
[ #################### ] 5.321s | Erase file - Done erasing
[error] [ Client] - Encountered error -102: Command program_file executed for 389 milliseconds with result -102
[error] [ nRF52] - The write access failed, but no cause could be determined.
[error] [ nRF52] - It may be due to an unaligned access, accessing a nonexistent memory, or a communication issue.
[error] [ nRF52] - Failed while performing 'Write' operation on target address 0x00000000.
-102: An unknown error.
[error] [ nRF52] - Failed while reading device information.
[error] [ Worker] - An unknown error.
ERROR: JLinkARM DLL reported an error. Try again. If error condition
ERROR: persists, run the same command again with argument --log, contact Nordic
ERROR: Semiconductor and provide the generated log.log file to them.
boggi@getshop-boggi:~/....$ nrfjprog --memwr 0x00000000 --val 0x12345678 -f NRF52 --log
Parsing parameters.
Writing.

boggi@getshop-boggi:~/....$ nrfjprog --memwr 0x20000000 --val 0x12345678 -f NRF52 --log
Parsing parameters.
Writing.

boggi@getshop-boggi:~/....$ nrfjprog --memwr 0x00000000 --val 0x12345678 -f NRF52 --log
Parsing parameters.
WARNING: Writing to a non-empty address may result in unexpected behavior.
Would you like to continue with the operation? [Y]/N
Writing.

boggi@getshop-boggi:~/....$ nrfjprog --memwr 0x00000000 --val 0x12345678 -f NRF52 --log
Parsing parameters.
WARNING: Writing to a non-empty address may result in unexpected behavior.
Would you like to continue with the operation? [Y]/N
Writing.

boggi@getshop-boggi:~/....$ nrfjprog --program /home/boggi/..../build_1/zephyr/zephyr.hex --sectoranduicrerase --verify -f NRF52 --snr 1050385234 --log
[ #################### ] 5.327s | Erase file - Done erasing
[error] [ Client] - Encountered error -102: Command program_file executed for 392 milliseconds with result -102
[error] [ nRF52] - The write access failed, but no cause could be determined.
[error] [ nRF52] - It may be due to an unaligned access, accessing a nonexistent memory, or a communication issue.
[error] [ nRF52] - Failed while performing 'Write' operation on target address 0x00000000.
-102: An unknown error.
[error] [ nRF52] - Failed while reading device information.
[error] [ Worker] - An unknown error.
ERROR: JLinkARM DLL reported an error. Try again. If error condition
ERROR: persists, run the same command again with argument --log, contact Nordic
ERROR: Semiconductor and provide the generated log.log file to them.

Is there anything I am missing here?

I attach the log for all executions above.

316576.log.log

I have also tried nrfjprog --recover --log, it executes correct, but does not help

[Edvin]

Hello,

First, can you please try:

nrfjprog --program /home/boggi/..../build_1/zephyr/zephyr.hex --recover --verify -f NRF52 --snr 1050385234

So exchange the --serialanduicrerase with --recover.

Next, for the remaining "small" writes, you should add "--verify"

What you are seeing is probably that you have the new nRF52840's which has a bit different readbackprotection. Therefore, if it is empty, readbackprotection is enabled, so the FW needs to unlock it. If you have the latest MDK, this is done automatically. 

And you should stick to the latest version of nrfjprog, as the older ones may not be aware of this new readback protection.

The reason --recover before doing the --program in two different options is that the recover will write a small application to the nRF, turning off readback protection. 

Give it a go, and let me know if it doesn't work.

Best regards,

Edvin

[Boggibill]

Hi Edvin.

Thanks for following me up.

I still get issues.

boggi@getshop-boggi:~/Downloads$ nrfjprog --program /home/boggi/..../build_1/zephyr/zephyr.hex --recover --verify -f NRF52 --snr 1050385234

[ #################### ] 1.113s | Erase file - Done erasing
[error] [ Client] - Encountered error -102: Command program_file executed for 397 milliseconds with result -102
[error] [ nRF52] - The write access failed, but no cause could be determined.
[error] [ nRF52] - It may be due to an unaligned access, accessing a nonexistent memory, or a communication issue.
[error] [ nRF52] - Failed while performing 'Write' operation on target address 0x00000000.
-102: An unknown error.
[error] [ nRF52] - Failed while reading device information.
[error] [ Worker] - An unknown error.
ERROR: JLinkARM DLL reported an error. Try again. If error condition
ERROR: persists, run the same command again with argument --log, contact Nordic
ERROR: Semiconductor and provide the generated log.log file to them.
NOTE: For additional output, try running again with logging enabled (--log).
NOTE: Any generated log error messages will be displayed.

boggi@getshop-boggi:~/Downloads$ nrfjprog --version
nrfjprog version: 10.24.2 external
JLinkARM.dll version: 7.94e
boggi@getshop-boggi:~/Downloads$

Attached log:

Fullscreen 8640.log.log Download

[Boggibill]

Hi.

Yes, i am sure I don't mix the SWDIO and SWDCLK. I am able to program other custom boards with a different chip (NRF52840-QFAA-F-R7).

Im not sure what the voltage is, I am powering using the DK, and the (the standard voltage on the DK).

Attached is a picture of the board.

[Edvin]

Boggibill said:

I am able to program other custom boards with a different chip (NRF52840-QFAA-F-R7).

Using this DK as the programmer?

Boggibill said:

I am powering using the DK, and the (the standard voltage on the DK).

As shown in this picture? If so, can you please try the following:

1: Disconnect the VDD_nRF on the far left, and plug it in VDD near the bottom of the picture. (not sure if this is needed, but it is worth a shot)

2: Disconnect the GND DETECT and plug it in GND near the bottom of the picture. 

3: Short GND to GND DETECT. 

(4: Keep the white cable, shorting VDD to VTG)

The reason is that GND DETECT is not actually ground. It is used to detect whether GND is GND on the connected device. So right now you are probably having a floating GND on your custom board, unless you power it externally. 

Best regards,

Edvin

[Boggibill]

Hi Edvin.

I will try what you say. It is not easy to see from the picture, but GND and GND detect are already connected here.

I tested connceting VDD to a different port, with no luck.

nrfjprog --recover --log works just fine.

[Edvin]

You can try to decrease the SWD speed. No offence, but this looks a bit home-made with a lot of connections that may not be 100%. 

Add the argument: 

--clockspeed 500

or

-c 500

and see if that changes anything. 

[Boggibill]

I know it is a bit "home-made". But i run out if wires and needed to remove soldered connection since that could be that somewhere it was improper connections. It is like this to make sure all connections where connected..

Anyway it did not help..

boggi@getshop-boggi:~$ nrfjprog --program /home/boggi/..../build_1/zephyr/zephyr.hex --recover --verify -f NRF52 --snr 1050385234 -c 500 --log
[ #################### ] 1.147s | Erase file - Done erasing
[error] [ Client] - Encountered error -102: Command program_file executed for 58 milliseconds with result -102
[error] [ nRF52] - The write access failed, but no cause could be determined.
[error] [ nRF52] - It may be due to an unaligned access, accessing a nonexistent memory, or a communication issue.
[error] [ nRF52] - Failed while performing 'Write' operation on target address 0x00000000.
-102: An unknown error.
[error] [ nRF52] - Failed while reading device information.
[error] [ Worker] - An unknown error.
ERROR: JLinkARM DLL reported an error. Try again. If error condition
ERROR: persists, run the same command again with argument --log, contact Nordic
ERROR: Semiconductor and provide the generated log.log file to them.

boggi@getshop-boggi:~$ nrfjprog --recover
Recovering device. This operation might take 30s.
Erasing user code and UICR flash areas.

boggi@getshop-boggi:~$ nrfjprog --program /home/boggi/..../build_1/zephyr/zephyr.hex --recover --verify -f NRF52 --snr 1050385234 --clockspeed 500 --log[ #################### ] 1.148s | Erase file - Done erasing
[error] [ Client] - Encountered error -102: Command program_file executed for 57 milliseconds with result -102
[error] [ nRF52] - The write access failed, but no cause could be determined.
[error] [ nRF52] - It may be due to an unaligned access, accessing a nonexistent memory, or a communication issue.
[error] [ nRF52] - Failed while performing 'Write' operation on target address 0x00000000.
-102: An unknown error.
[error] [ nRF52] - Failed while reading device information.
[error] [ Worker] - An unknown error.
ERROR: JLinkARM DLL reported an error. Try again. If error condition
ERROR: persists, run the same command again with argument --log, contact Nordic
ERROR: Semiconductor and provide the generated log.log file to them.
boggi@getshop-boggi:~$

Attached log

4454.log.log

BTW; I have not nReset connected, could that cause this problems?

[Edvin]

Boggibill said:

BTW; I have not nReset connected, could that cause this problems?

Should not be needed. The debugger usually uses software reset, not pin reset.

Does flashing that particular firmware work if you flash it to another nRF52840 device, like a DK? (I don't care if it doesn't run, but if it is possible to just flash it).

And similarly, does it work programming other .hex files to that particular board?

And finally, can you try with another DK as a debugger, or even an external debugger with your custom board.

Best regards,

Edvin

[Boggibill]

Does flashing that particular firmware work if you flash it to another nRF52840 device, like a DK? (I don't care if it doesn't run, but if it is possible to just flash it).

Yes

And similarly, does it work programming other .hex files to that particular board?

No

And finally, can you try with another DK as a debugger, or even an external debugger with your custom board.

I don't have another DK, but I am able to program other custom boards the same way with the same DK, so I don't think there is a problem with the DK.

[Edvin]

Ok, so you have one custom board that can't be programmed, and you don't have an external debugger to test with.

So do you have several physical copies of that same custom board? And some of them are working, but one particular does not work?

Or does none of that custom board work?

Did the faulty device work at some point? Or did it never work?

Best regards,

Edvin

[Boggibill]

Hi.

I have different version of a custom board that works, but none of the same copy works here.

They faulty one have never worked.

[Edvin]

Could it be soldering issues? Perhaps the chip is not properly soldered on the board?

Unless you have an external debugger to test with, then I would say that you need to try to look at the soldering, or send it to us if you suspect it is a faulty device. In that case, we can desolder the chip, and test it in a socket board that we have. 

Alternatively, what you can do first is to send us your schematics and PCB layout files for review. In that case, please create a new ticket, so that it will be assigned to someone who knows what to look for in PCB reviews (because I don't). 

Best regards,

Edvin