• State Not Answered
  • Replies 9 replies
  • Subscribers 74 subscribers
  • Views 196 views
  • Users 0 members are here
Attachments (1) Download All
Nordic Case Info
  • Case ID: 347030
Options

Flashing on PCB gives Unknown Error in J-Link DLL

SohamGhugare

Hey Team,

I'm trying to flash the audio application on our custom PCB, this PCB follows the interfaces of the nrf5340 audio dk. Previously on lower SDK versions (2.7-2.9), I was able to flash my programs without any errors. However now with the newer toolchain version (3.0.1), Im getting this error whenever i run the west flash command

Command:

`west flash -d /opt/nordic/ncs/v3.0.1/nrf/applications/nrf5340_audio/build --domain nrf5340_audio --dev-id 801055229 --recover`

Logs:

Flashing nrf5340_audio to 801055229
west flash -d /opt/nordic/ncs/v3.0.1/nrf/applications/nrf5340_audio/build --domain nrf5340_audio --dev-id 801055229 --recover

-- west flash: rebuilding
[0/10] Performing build step for 'ipc_radio'
ninja: no work to do.
[1/10] Performing build step for 'nrf5340_audio'
ninja: no work to do.
[4/10] cd /opt/nordic/ncs/v3.0.1/nrf/applications/nrf5340_audio/build/_sysbuild && /opt/nordic/ncs/toolchains/ef4fc6722e/Cellar/cmake/3.21.0/bin/cmake -E true
[6/9] No install step for 'nrf5340_audio'
[7/9] Completed 'nrf5340_audio'
[8/9] cd /opt/nordic/ncs/v3.0.1/nrf/applications/nrf5340_audio/build/_sysbuild && /opt/nordic/ncs/toolchains/ef4fc6722e/Cellar/cmake/3.21.0/bin/cmake -E true
-- west flash: using runner nrfutil
-- runners.nrfutil: reset after flashing requested
-- runners.nrfutil: Recovering and erasing flash memory for both the network and application cores.
-- runners.nrfutil: Flashing file: /opt/nordic/ncs/v3.0.1/nrf/applications/nrf5340_audio/build/merged.hex
-- runners.nrfutil: Recover
-- runners.nrfutil: Recover
-- runners.nrfutil: Erasing address ranges touched by firmware
Error: One or more batch tasks failed:
 * 801055229: Device error: Emulator error: Unknown Error in J-Link DLL (error code =-1) (Generic)

FATAL ERROR: command exited with status 1: nrfutil --json device x-execute-batch --batch-path /opt/nordic/ncs/v3.0.1/nrf/applications/nrf5340_audio/build/generated_nrfutil_batch.json --serial-number 801055229

Sometimes I also get this error randomly

Error: One or more batch tasks failed:
 * 801055229: Device error: Failed to read from memory address 0x500038e4: Failed to write DebugPort register 0x08: Unknown Error in J-Link DLL (error code =-1) (Generic)

What should be the cause of this error and how do I fix it? Please let me know if you require any further information.

PS: Relevant information about the PCB like schematics and stuff are already shared in the private threads with this same account. 

Regards,

Soham

Parents
  • 0

    Hello,

    Thanks for explaining the scenario in detail, it helped clarify some of the confusion.

    From the log, it looks like nrfutil-device detects that write/erase protection is enabled on a memory range by the running firmware. It then tries to disable it using a system reset. This reset is handled by J-Link, but it fails badly—something goes wrong during the reset, and when J-Link tries to reconnect to the core, that also fails and is retried a few times. As a result, the next operation fails because J-Link seems to have powered down the debug regions or something similar.

    From the nrfjprog log, it doesn't appear to attempt clearing the erase protection using a system reset at this point. However, the firmware might not have been running due to side effects from earlier operations. So could you please try running the following commands:

    nrfjprog --program /Users/soham/ksham/pcb-tests/led-test/build/merged.hex --chiperase --pinreset

nrfjprog --program /Users/soham/ksham/pcb-tests/led-test/build/merged.hex --chiperase --log log.txt

    From the shared log, I see this error:
    * 801055229: Device error: Failed to read from memory address 0x500038e4: Failed to write DebugPort register 0x08: Unknown Error in J-Link DLL (error code = -1)

    However, the error you mentioned in your response:
    * 801055229: Device error: Emulator error: Unknown Error in J-Link DLL (error code = -1) (Generic) is missing.

    I’d appreciate it if you could rerun the command to try to reproduce the missing error, so we can investigate further. Ideally, you should keep running the command until the first error appears again. But even if it doesn't, sharing the full log from multiple attempts, maybe limit it to 5 tries, would still be helpful.

    Kind Regards,

    Abhijith

Reply
  • 0

    Hello,

    Thanks for explaining the scenario in detail, it helped clarify some of the confusion.

    From the log, it looks like nrfutil-device detects that write/erase protection is enabled on a memory range by the running firmware. It then tries to disable it using a system reset. This reset is handled by J-Link, but it fails badly—something goes wrong during the reset, and when J-Link tries to reconnect to the core, that also fails and is retried a few times. As a result, the next operation fails because J-Link seems to have powered down the debug regions or something similar.

    From the nrfjprog log, it doesn't appear to attempt clearing the erase protection using a system reset at this point. However, the firmware might not have been running due to side effects from earlier operations. So could you please try running the following commands:

    nrfjprog --program /Users/soham/ksham/pcb-tests/led-test/build/merged.hex --chiperase --pinreset

nrfjprog --program /Users/soham/ksham/pcb-tests/led-test/build/merged.hex --chiperase --log log.txt

    From the shared log, I see this error:
    * 801055229: Device error: Failed to read from memory address 0x500038e4: Failed to write DebugPort register 0x08: Unknown Error in J-Link DLL (error code = -1)

    However, the error you mentioned in your response:
    * 801055229: Device error: Emulator error: Unknown Error in J-Link DLL (error code = -1) (Generic) is missing.

    I’d appreciate it if you could rerun the command to try to reproduce the missing error, so we can investigate further. Ideally, you should keep running the command until the first error appears again. But even if it doesn't, sharing the full log from multiple attempts, maybe limit it to 5 tries, would still be helpful.

    Kind Regards,

    Abhijith

Children
No Data
Related
Terms of service