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.

[Johan]

Done

Funny how the upvote becomes red...as in warning...it should be green haha

Red for downvotes arrow..

[Johan]

How is the fix going?

I still have to flash twice before it works (through shell).

But I WANT to get rid of this dual flashing, time wasting procedure.

When is the fix done?

What is stopping you from finishing it?

Do you need help?

Bjørn Kvaale

[Johan]

Ping! The 24h promise in Nordic's PDF (from meeting with them) doesn't seem to apply in reality...

[Johan]

Ok it's been a weekend, I forgot that ;-)

[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.