Since Nordic SDK release v1.0.0 our nRF9160 start having issues flashing and erasing. Coincidence?

[Johan]

Hi,

I'm using the latest release of software V1.0.0 with the nRF9160 DK and today started flashing the examples.

at_client worked fine (just tried flashing it once, but remember there was something going on there as well).
the sample application asset_tracker worked first time, I made some modifications to the code, and flashing it after, is very problematic.
See the log below.
* Erasing sectors fails.
* RAM doesn't respond in time..
I had to try several times, and also try to manually "erase all" but even that option took several tries before succeeding.

/Johan

LOG

Connecting ‘J-Link’ using ‘USB’
Connecting to target using SWD
Loaded F:/arm_segger_embedded_studio_v418_win_x64_nordic/bin/JLink_x64.dll
Firmware Version: J-Link OB-K22-NordicSemi compiled Feb 14 2019 14:03:18
DLL Version: 6.46h
Hardware Version: V1.00
Target Voltage: 3.300
Device "NRF9160" selected.
Found SW-DP with ID 0x6BA02477
Scanning AP map to find all available APs
AP[5]: Stopped AP scan as end of AP map seems to be reached
AP[0]: AHB-AP (IDR: 0x84770001)
AP[1]: AHB-AP (IDR: 0x24770011)
AP[2]: AHB-AP (IDR: 0x84770001)
AP[3]: APB-AP (IDR: 0x54770002)
AP[4]: JTAG-AP (IDR: 0x12880000)
Iterating through AP map to find AHB-AP to use
AP[0]: Core found
AP[0]: AHB-AP ROM base: 0xE00FF000
CPUID register: 0x410FD212. Implementer code: 0x41 (ARM)
Found Cortex-M33 r0p2, Little endian.
FPUnit: 8 code (BP) slots and 0 literal slots
Security extension: implemented
Secure debug: enabled
CoreSight components:
ROMTbl[0] @ E00FF000
ROMTbl[0][0]: E000E000, CID: B105900D, PID: 000BBD21 Cortex-M33
ROMTbl[0][1]: E0001000, CID: B105900D, PID: 000BBD21 DWT
ROMTbl[0][2]: E0002000, CID: B105900D, PID: 000BBD21 FPB
ROMTbl[0][3]: E0000000, CID: B105900D, PID: 000BBD21 ITM
ROMTbl[0][5]: E0041000, CID: B105900D, PID: 002BBD21 ETM
ROMTbl[0][6]: E0042000, CID: B105900D, PID: 000BBD21 CTI
Preparing target for download
Executing Reset script TargetInterface.resetAndStop()
Reset: Halt core after reset via DEMCR.VC_CORERESET.
Reset: Reset device via AIRCR.SYSRESETREQ.
Reset: CPU may have not been reset (DHCSR.S_RESET_ST never gets set).
Reset: Using fallback: Reset pin.
Reset: Halt core after reset via DEMCR.VC_CORERESET.
Reset: Reset device via reset pin
Reset: VC_CORERESET did not halt CPU. (Debug logic also reset by reset pin?).
Reset: Reconnecting and manually halting CPU.
Found SW-DP with ID 0x6BA02477
AP map detection skipped. Manually configured AP map found.
AP[0]: AHB-AP (IDR: Not set)
AP[0]: Core found
AP[0]: AHB-AP ROM base: 0xE00FF000
CPUID register: 0x410FD212. Implementer code: 0x41 (ARM)
Found Cortex-M33 r0p2, Little endian.
Erasing Chip
J-Link: Flash download: Total time needed: 0.211s (Prepare: 0.032s, Compare: 0.000s, Erase: 0.172s, Program: 0.000s, Verify: 0.000s, Restore: 0.007s)
J-Link: Flash download: Total time needed: 0.213s (Prepare: 0.034s, Compare: 0.000s, Erase: 0.171s, Program: 0.000s, Verify: 0.000s, Restore: 0.007s)
Timeout while erasing sectors, RAMCode did not respond in time. (PC = 0x00000000, CPSR = 0x00000000, LR = 0x01000003)!
Failed to erase sectors.
J-Link: Flash download: Total time needed: 20.736s (Prepare: 0.034s, Compare: 0.000s, Erase: 20.690s, Program: 0.000s, Verify: 0.000s, Restore: 0.011s)
Preparing target for download
Executing Reset script TargetInterface.resetAndStop()
Reset: Halt core after reset via DEMCR.VC_CORERESET.
Reset: Reset device via AIRCR.SYSRESETREQ.
Erasing Chip
J-Link: Flash download: Total time needed: 0.243s (Prepare: 0.047s, Compare: 0.000s, Erase: 0.172s, Program: 0.000s, Verify: 0.000s, Restore: 0.024s)
J-Link: Flash download: Total time needed: 0.245s (Prepare: 0.049s, Compare: 0.000s, Erase: 0.172s, Program: 0.000s, Verify: 0.000s, Restore: 0.024s)
J-Link: Flash download: Total time needed: 21.993s (Prepare: 0.077s, Compare: 0.000s, Erase: 21.866s, Program: 0.000s, Verify: 0.000s, Restore: 0.049s)

[GNotman]

I've been trying v1.0.0 today and experienced the same issue.

My current work around is as follows:

1. Target->Connect J-Link
2. Target->Erase All (this seems to get stuck one step into the erase bar)
3. Reset the target board or wait for step 2 to timeout
4. Target->Disconnect J-Link (this is a must)

After which Target->Download zephyr/merged.hex seems to work fine.

[Bjørn Kvaale]

This is a known issue with Segger. I am currently using Segger J-Link v6.44e, but I see the same issue there. What normally works is to try to program one or two times. It normally works on the second time. I will update this case when we have a fix for this.

[Bjørn Kvaale]

The fix is unfortunately not done yet. I will update this post as soon as I have heard of a fix. I fully agree that it is not a very elegant solution. You could erase the flash first via nrfjprog -e & then flash. Then, you will only need to flash one time. Please ask your local Regional Sales Manager for more info.

[Johan]

Thanks.

Is Nordic actively pursuing to complete this fix soon if I don't keep asking about progress?
I feel like I'm babysitting the progress on this task currently, and I would not like that.

[Bjørn Kvaale]

I have sent an email to your local RSM, who should be able to give you a timeline regarding this fix. The newest nrfjprog will fix this issue.

Update: The newest release of nrfjprog just came out today.

[Johan]

Thanks Bjorn!

[Bjørn Kvaale]

Johan, I will update this thread as soon as the new nrfjprog is out.

[Bjørn Kvaale]

Johan, the new release of nrfjprog v10.4.0 just came out today. I have tested myself & have not been able to reproduce the error anymore. Seems everything is fixed!

Update: This fixes the "could not verify programming" issue when using command line to program, but does not fix the issue in SES yet unfortunately. This is because SES uses JLINK directly & the bug is still present there it seems. I will report this internally.

[Johan]

Great! I will download it and test it!

[Johan]

My feedback:

1) cmdline flashing works 1st try every time. Good, it has improved from twice to single flashing.

2) Running from Segger Embedded Studio (V4.20a) still fails and locks up like before. I was expecting this to be solved in this fix. Why wasn't it? It's verifiable. It hangs after compare, then fails after 15-20 secs - "undocumented error"



Choosing to manually "erase all" in the menu, allows pressing the "run"-button and that makes it flash and start the application, correctly.

So there are still bugs to fix. Will you feedback these to the team?

[Bjørn Kvaale]

This happened the first time. Try to do an eraseall via command line first (nrfjprog -e), then program a separate hex file via command line & then program your application via SES again. You can then program the first hex file via command line:

nrfjprog --program merged.hex -f nrf91 --sectorerase --verify

& then program via SES again. You can continue this loop a few times. After the first error, I never saw this error again.

If you still see the error, you may want to try to use the latest version of SES.

[Johan]

I'm trying your suggestions.

Newer Segger version:
To download a version newer than 4.20a isn't possible. From using your nRF Connect V3.2.0-tool to download the nordic-version of segger, it only gives me 4.20a. On the segger homepage there is a version 4.22, but using that one, just forces me to request a valid license through email from nordic, and putting that licence in, doesnt open up segger to nordic projects. The "Open nRF connect...SDK"-menu option under "File" isn't there. And every time I restart the segger 4.22 it asks for a valid licence over and over again. It doesn't work.

And your solution above, worked 1 time.
I erased all via commandline.
I flashed another hex via commandline.
I built my SES application vid RUN and it flashed.
Looked good and it starts and the change in printk message is different.
I try it again in SES, modify the printk message and press run.
Now it hangs on the Erase operation like before.

The bug isn't fixed. Sorry Nordic. More debugging to do.