Cannot flash NRF52832 with Segger JLink device after a full day of flashing normally

I am having an issue flashing from VS Code using NCS v2.4.0 and a Segger JLink programmer. Things work just fine for a long time, then I have issues flashing the device with the following output:

-- west flash: using runner nrfjprog
-- runners.nrfjprog: Flashing file: z:\home\jhaws\git\brickyard_ptu\communication\ptu_app\_bld\zephyr\zephyr.hex
[error] [ Client] - Encountered error -220: Command read_device_info executed for 10011 milliseconds with result -220
[error] [ Worker] - 10 second timeout elapsed, no time left to wait for debug port to power up.
[error] [ Client] - Encountered error -220: Command read_memory_descriptors executed for 10017 milliseconds with result -220
Failed to read device memories.
[error] [ Worker] - 10 second timeout elapsed, no time left to wait for debug port to power up.
ERROR: Operation failed due to timeout. Check the log messages for more details.
NOTE: For additional output, try running again with logging enabled (--log).
NOTE: Any generated log error messages will be displayed.
FATAL ERROR: command exited with status 64: nrfjprog --program 'z:\home\jhaws\git\brickyard_ptu\communication\ptu_app\_bld\zephyr\zephyr.hex' --sectoranduicrerase --verify -f NRF52 --snr 59200863

I am unsure what is causing this because it seems to resolve itself after an indetermined amount of time.

I got in this the last time when I had a debug session open and I powered off the device before disconnecting. When I powered on again and tried to start a debug session through VS Code, I get this error.

Thanks for the support!

Jon

  • I also ran this and got this result:

    PS C:\Users\jonathan.haws> nrfjprog.exe --recover -f NRF52 --log
    Recovering device. This operation might take 30s.
    [error] [ Client] - Encountered error -21: Command recover executed for 10020 milliseconds with result -21
    [error] [ Worker] - 10 second timeout elapsed, no time left to wait for debug port to power up.
    ERROR: Recover failed. Please make sure that the correct device family is given
    ERROR: and try again.

  • Hello Jon, 

    Is this a DK or a custom board? If it is a custom board, could you expand a bit on how you are programming it?

    Regards,

    Elfving

  • This is a custom board. We are just programming with SWD, similar to how the dev kits are done, but we use an external Segger JLink base instead of an onboard chip.

    I'm not an expert on how the programmers work, but VS code can see the device (the programmer) and when I click debug, it runs a the nrfjprog command to flash the image to the board then start the debugger. It works fine a lot of the time, but there seems to be a sequence of operations that makes the chip invisible for a period of time and even power cycling the target doesn't clear it out.

    We have the SWDIO/RESET and SWDCLK lines of the nrf52832 run out to Tagconnect pads on our board and we connect our programmer to that via ribbon cable.

    What other details would you like to know?

    Thanks for the help!

  • jrhaws said:
    Thanks for the help!

    No problem at all, though I should mention that there might be some delays here on DevZone during these summer months due to vacations and low staffing. Though we are starting to get out of that phase now.

    jrhaws said:
    we use an external Segger JLink base instead of an onboard chip.

    Great, just wondered if it was an external programmer from another DK.

    As the custom board has worked for a while I assume the board layout is fine, though out of curiosity: have you gotten the hardware reviewed?

    Are you able to flash anything else, eg. other copies of this custom board, with this programmer?

    Regards,

    Elfving

  • Elfving,

    Yes, I can flash other boards (and this particular board) just fine many times.

    However, sometimes the system seems to get into a state where it cannot flash at all - like it cannot communicate with the programmer.

    I have been running VS Code off a shared drive with a WSL installation, so maybe that was playing into this as well.

    I'll share schematics as soon as I can verify our NDA with you guys.

    Thanks for the support!

    Jon

Related