nRF52840 - Old one works, new one doesn't

[David Ormand]

We had three nRF52840DK boards (PCA10056) for several years for use in development.  Then one died (or to be fair, I killed it), so we got two more that turned out to be newer.

I've got both the nRF Command Line Tools (e.g., nrfjprog) and nrfutil.  I understand nrfjprog is slated for obsolescence, so I'd like to switch to nrfutil, except that nrfutil does not yet support writing (and reading) to flash blocks or UICR addresses, and I must have that.  So nrfjprog is still the go-to tool.

What I'm seeing is that I can reliably program both old and new DKs with either tool.

Now, I'm using these DKs as programmers for the target hardware.  The target has a Tag-Connect footprint, and I'm using a 6-inch TC2030-CTX-NL cable.

The old DK works flawlessly, every time.  The new DK does not.

Furthermore, when I have the programming cable connected (to DEBUG_OUT, P19) and just hanging (a transmission-line stub?), the old DK will respond to commands but the new one never does.

So, with the cable hanging there, the new DK gets the following errors:

D:\home\dormand\>nrfjprog -f NRF52 --program project.hex --verify --chiperase --pinreset
[error] [ Client] - Encountered error -102: Command read_device_info executed for 140 milliseconds with result -102
[error] [ Worker] - An unknown error.
[error] [ Client] - Encountered error -102: Command read_memory_descriptors executed for 30 milliseconds with result -102
Failed to read device memories.
[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.

D:\home\dormand>nrfutil device program --firmware project.hex --options verify=VERIFY_READ,reset=RESET_PIN
[00:00:00] ------ 0% [1050227132] Failed, [jlink] JLINKARM_DLL_ERROR
Error: One or more program tasks failed:
* 1050227132: [jlink] JLINKARM_DLL_ERROR, code: Nrfjlink

More info - taking the stub programming cable off the new board (it won't respond to _anything_ with the cable present),

D:\home\dormand>nrfutil device device-info
serial_number: 000683450546
    boardVersion: PCA10056
    deviceFamily: NRF52_FAMILY
    deviceVersion: NRF52840_xxAA_REV2
    jlinkObFirmwareVersion: J-Link OB-SAM3U128-V2-NordicSemi compiled Jun 25 2024 17:06:37
    protectionStatus: NRFDL_PROTECTION_STATUS_NONE
serial_number: 001050227132
    boardVersion: PCA10056
    deviceFamily: NRF52_FAMILY
    deviceVersion: NRF52840_xxAA_REV3
    jlinkObFirmwareVersion: J-Link OB-nRF5340-NordicSemi compiled Oct 30 2023 12:13:06
    protectionStatus: NRFDL_PROTECTION_STATUS_NONE

Error: Failed to device info one or more devices:
* id:8: No matching plugin found for operations to execute, code: UnsupportedDevice

I see both the device version is different and the JLink firmware is _Very_ different.  Very surprised to see anything "nrf5340" on a nRF52840DK board.

I believe I've seen the means on the DevZone for replacing the firmware, but I am reluctant to do so, since without the cable the board _does_ in fact program and _sometimes_ can succeed in programming a target.  This seems to be more of a hardware problem, if merely the presence of a 6-inch stub on P19 prevents the JLink from doiong _anything_.

My other newer DK behaves the same exact way.

D:\home\dormand>nrfutil device device-info
    serial_number: 001050268011
    boardVersion: PCA10056
    deviceFamily: NRF52_FAMILY
    deviceVersion: NRF52840_xxAA_REV3
    jlinkObFirmwareVersion: J-Link OB-nRF5340-NordicSemi compiled Oct 30 2023 12:13:06
    protectionStatus: NRFDL_PROTECTION_STATUS_NONE

Error: Failed to device info one or more devices:
* id:7: No matching plugin found for operations to execute, code: UnsupportedDevice

[sly]

Hi David,

I do not have the exact nRF52840-DK that you are using.  But yes our newer nRF52 and nRF5340-DK are using the nrf5340 with special firmware from Segger as the Segger J-Link OB.  I definitely don't recommend reprogramming that SoC -- the firmware that goes on this nRF5340 is not available.  We stopped using the JLink OB chip (non Nordic version) on the DKs since we could not purchase them during the 2020-2022 allocation days.

Yes nRF Command Line Tool is slated to be obsoleted but you are good for the near term.  And you have the correct version of nRF Util installed.

I am not sure which of the the following you are doing but you might want to try the other method to see if that makes a difference.

It's recommended to power the external board separately from the DK. The voltage on the external board must match that of the DK (typically 3V when powered through USB).

If you're using the DK to power the target, make sure you've shorted the solder bridge SB47, but be cautious not to connect a separate power supply to the external board when SB47 is shorted nRF52840 DK User Guide.

I have used the same Tag-Connect TC2030-CTX-NL cable so I don't think there should be any issues there.  It is not that long of a cable.

I will turn control of this ticket back to our support team.  

Thanks

Mike Sly

 

[David Ormand]

I'm not powering the target from the DK.

I've just finished using the "new" DK to reprogram a set of target hardware today.  Worked every time.  My customer, OTOH, is having spotty results.  I can't actually say I have a lot of personal experience with programming with the "new" DK, since I've got my "old" DK serving in that role.  I think I'm going to swap them, though.

What really blows me away, though, is how an "old" DK doesn't care if the stub cable is on P19 but the "new" DK absolutely refuses to do anything.  Like you say, a 6-inch stub isn't much of a stub.

[PaKa]

There was a change in how the kit determines what programming port to use when we moved from the older OBDs to the nRF5340 OBDs. If you have followed the instructions to the letter and have ALL the signals wired then it should work seamlessly but if you have not wired all/done something not standard then you may see unexpected behavior.

Recommendation is to check out the nRF52 DK user guide on our documentation siite, docs.nordicsemi.com/.../ext_programming_support_P19.html, (I have not gotten all the DK user guides updated yet) and see if your setup is correct according to this user guide (the new nRF52840 DKs have the same circuitry for external programming as new nRF52 DKs).

[David Ormand]

As mentioned above, I'm using a Tag-Connect TC2030 cable for programming.  TC2030 is a six-pin footprint.  Of the ten signals from P19, pins 7 and 8 are not connected, and pins 3, 5, and 9 are connected together _in the cable_.  I see that pin 3 is SWDO_SELECT.  So when the cable is connected to P19, SWDO_SELECT will be shorted to ground _in the cable_.

Also as mentioned, I'm not powering the target through the cable.  So SB47 (corresponds to SB32 on the nRF52DK) remains in its as-delivered "open" state.

Question: In the previous ODB, was P19 used if BOTH SWDO_SELECT is grounded AND pin 1 sees target voltage?  This would explain why my older DK doesn't care if the cable is present.  And in the newer ODB, P19 is used if SWDO_SELECT is grounded without looking if pin 1 sees target voltage?  So by merely having the cable connected, it thinks there's a target connected, but since there isn't actually a powered target connected, the JLink won't work?  This would explain why the newer DK won't do anything when the cable is connected but just hanging (a stub).

If this is the case, this explains why programming doesn't work.  It doesn't explain so much why
    nrfutil device device-info
doesn't work, which appears to be talking directly to the OBD (reports board ID and firmware version, nothing to do with an external target).

Interesting: The PCA10056 schematic shows a SB19 that connects pin 1 of P19 to VIO_REF.  On the newer DK, I see SB19 right next to SB47 adjacent to P19.  On the older DK, there is only SB47, which suggests to me that on the older DK, the voltage on P19-1 is being monitored under all circumstances.  Aha!  Yes, if I pull down the hardware files for board version 2.1.0, P19-1 is connected to EXT_VTG; no solder bridge.  Furthermore, the DK User Guide lists all the solder bridges EXCEPT for SB19.  Hence the statement in the DK User Guide (which apparently has not been updated for the newer design):

"When the external board is powered, the interface MCU will detect the supply voltage of the board and
program/debug the target chip on the external board instead of the onboard nRF52840 SoC."

This is interesting, but this doesn't explain why my customer is having problems reliably programming powered external targets through P19 / TC2030.  There does not appear to be a technical reason.