• State Verified Answer
  • Replies 3 replies
  • Subscribers 64 subscribers
  • Views 187 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 326525
Options

Cannot flash external board through custom connector on an nRF52832 DK that uses the J-Link OB-nRF5340

efischer

I'm running into issues with programming external boards (an NRF52832_xxAA_REV2, an NRF52810_xxAA_REV2, an NRF51xxx_xxAC_REV3, and an NRF52832_xxAA_REV3) through a custom connector on an nRF52 DK that uses the J-Link OB-nRF5340 and can't figure out what's going wrong, This only seems to be a problem with the nRF5340 programmer (PCA10040 Rev 3.0.0), because I have two dev kits with an older J-Link programmer (PCA10040 Rev 1.2.4 & PCA10028 Rev 1.2.0)  that work just fine. 

 



Here's how I have the connector hooked up (which I found at https://infocenter.nordicsemi.com/index.jsp?topic=%2Fug_nrf52832_dk%2FUG%2Fdk%2Frevision_history.html)

I'm using J-Link v7.96f (though I've also tried this with v7.94f and the results are the same) 

The J-Link OB-nRF5340 is running the 4/11/24 firmware:

When using nRF Connect for Desktop (v4.4.1) Programmer (v4.3.0) to program the device (for example the NRF52832_xxAA_REV2) through the DK with the J-Link nRF5340, after clicking "Erase all", loading my firmware file, and hitting "Erase & write" I get these errors: 

15:45:38.257
Failed to writing hex to application core core. Error: [object Object], message: Batch task program failed, [jlink] JLINKARM_DLL_ERROR
15:45:38.501
Error: Failed with exit code 1. One or more batch tasks failed: - [jlink] JLINKARM_DLL_ERROR, code: Nrfjlink. Message: Batch task program failed, [jlink] JLINKARM_DLL_ERROR.
When using the same version of nRF Connect for Desktop and Programmer to program the device through the DK with the older J-Link I get zero errors and the device is flashed successfully. 
When trying to program the device using the J-Link cli, I can connect to the device without any issues, but it fails to erase the chip:

SEGGER J-Link Commander V7.96f (Compiled Apr 24 2024 14:14:02)
DLL version V7.96f, compiled Apr 24 2024 14:13:07

Connecting to J-Link via USB...O.K.
Firmware: J-Link OB-nRF5340-NordicSemi compiled Apr 11 2024 17:44:26
Hardware version: V1.00
J-Link uptime (since boot): 0d 00h 07m 24s
S/N: 1050324489
License(s): RDI, FlashBP, FlashDL, JFlash, GDB
USB speed mode: Full speed (12 MBit/s)
VTref=3.300V


Type "connect" to establish a target connection, '?' for help
J-Link>device NRF52
J-Link>si SWD
Selecting SWD as current target interface.
J-Link>speed 4000
Selecting 4000 kHz as target interface speed
J-Link>connect
Device "NRF52" selected.


Connecting to target via SWD
InitTarget() start
InitTarget() end - Took 2.68ms
Found SW-DP with ID 0x2BA01477
DPIDR: 0x2BA01477
CoreSight SoC-400 or earlier
Scanning AP map to find all available APs
AP[2]: Stopped AP scan as end of AP map has been reached
AP[0]: AHB-AP (IDR: 0x24770011)
AP[1]: JTAG-AP (IDR: 0x02880000)
Iterating through AP map to find AHB-AP to use
AP[0]: Core found
AP[0]: AHB-AP ROM base: 0xE00FF000
CPUID register: 0x410FC241. Implementer code: 0x41 (ARM)
Found Cortex-M4 r0p1, Little endian.
FPUnit: 6 code (BP) slots and 2 literal slots
CoreSight components:
ROMTbl[0] @ E00FF000
[0][0]: E000E000 CID B105E00D PID 000BB00C SCS-M7
[0][1]: E0001000 CID B105E00D PID 003BB002 DWT
[0][2]: E0002000 CID B105E00D PID 002BB003 FPB
[0][3]: E0000000 CID B105E00D PID 003BB001 ITM
[0][4]: E0040000 CID B105900D PID 000BB9A1 TPIU
[0][5]: E0041000 CID B105900D PID 000BB925 ETM
Memory zones:
Zone: "Default" Description: Default access mode
Cortex-M4 identified.
J-Link>erase
No address range specified, 'Erase Chip' will be executed
'erase': Performing implicit reset & halt of MCU.
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
Erasing device...

****** Error: Verification of RAMCode failed @ address 0x2000041C.
Write: 0x481CF815 D3024284
Read: 0x481CF895 D3024284
Failed to prepare for programming.
Failed to download RAMCode!
ERROR: Erase returned with error code -1.
When I try to load a file anyway, I get a similar error:

J-Link>loadfile "C:\Users\ejfis\Documents\firmware.hex"
'loadfile': Performing implicit reset & halt of MCU.
Reset: Halt core after reset via DEMCR.VC_CORERESET.
Reset: Reset device via AIRCR.SYSRESETREQ.
Downloading file [C:\Users\ejfis\Documents\firmware.hex]...

****** Error: Verification of RAMCode failed @ address 0x2000021C.
Write: 0x9400E00C 002A003B
Read: 0x9400F00C 002A003B
Failed to prepare for programming.
Failed to download RAMCode!
Unspecified error -1
Again, on dev kits with the older J-Link programmer, this is not an issue. 

The same thing happens when using the actual J-Link v7.96f JFlash.exe program:
We use these dev kits for programming our devices both during development and in production, one of our older dev kits that's been in use in production for a while now has given out, and the only one we have to replace it with is one with this newer nRF5340 J-Link programmer, which we can't get to work, which has suspended production of one of our devices. Any help ASAP would be greatly appreciated, thank you!
Parents
  • 0

    Hi efischer,

    It looks like you encountered the issue discussed in this case:  nRF 52840DK debug out on board version 3.0.0 not working . Could you please take a look and see if that is it?

    Hieu

  • 0 in reply to Hieu

    Hello, Hieu, thank you for the suggestion, although I don't believe that post contains my solution, it did lead me to it. I saw that it was mentioned that the chip requires the debugger to have the same voltage level as the chip, so I did some investigative work with a multimeter to ensure both were 3V, and eventually this led me to discover that GND DETECT on the newer dev kit with the nRF5340 J-Link was not connected to common ground as it was on the older dev kit. To quickly test my theory that this difference was the issue, I shorted GND DETECT and GND and afterwards could flash our devices successfully. That said, the manufacturing team had already set theirs up that way, and so we're not really sure what the issue was over there, but I've been informed they've finally gotten it to work on their end, so crisis averted. 

Reply
  • 0 in reply to Hieu

    Hello, Hieu, thank you for the suggestion, although I don't believe that post contains my solution, it did lead me to it. I saw that it was mentioned that the chip requires the debugger to have the same voltage level as the chip, so I did some investigative work with a multimeter to ensure both were 3V, and eventually this led me to discover that GND DETECT on the newer dev kit with the nRF5340 J-Link was not connected to common ground as it was on the older dev kit. To quickly test my theory that this difference was the issue, I shorted GND DETECT and GND and afterwards could flash our devices successfully. That said, the manufacturing team had already set theirs up that way, and so we're not really sure what the issue was over there, but I've been informed they've finally gotten it to work on their end, so crisis averted. 

Children
Related