• State Not Answered
  • Locked Locked
  • Replies 9 replies
  • Subscribers 63 subscribers
  • Views 4420 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 109333
Options
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Failure to loadfile binary to my PCB w/ nRF51822 using nRF51 DK Debug Out

i_am_trying

I have built a PCB that uses the nRF51822 . I am failing to load the binary onto the chip via the nRF51 DK. I can:

connect to the nRF51822 on my mac using the JLinkExe.

execute the erase command in JLink I have a small binary called LED_TEST.hex that I attempt to load. No matter how many times I run loadfile, I get the message:

Downloading file [LED_TEST.hex]...Info: J-Link: Flash download: Restarting flash programming due to program error (possibly skipped erasure of half-way erased sector). Info: J-Link: Flash download: Skip optimizations disabled for second try. Error while programming flash: Programming failed.

I'm looking for ideas on how to best debug this. I have a file that I logged the SWD traffic into. I am new to SWD traffic, and there are A LOT of records...so i'm not sure where would be the best place to focus within the SWD traffic in order to tip me off why this is happening. Here is the log file: LBL_SWD_loadfile.txt

Parents
  • 0

    That log I think shows you're really not connected to the SWD port at all. There's a few bit sequences in there that are impossible, for instance the writes to the ABORT register may not return WAIT or FAULT, similarly reads from the CTRL/STAT register may not return WAIT or FAULT. In general there are way too many FAULTS there. Also I believe with overrun detection turned on, the stickyoverrun flag should get set by the faults and according to that trace it's not.

    What produces that trace? It's possible whatever is doing that is entirely confused and unsequenced and is decoding rubbish. Because I'm surprised you can even get the debugger connected if you have that many issues. Do you get a reasonable connection response to the initial connect on the JLink?

    You could try dropping the SWD speed down, if you have some electrical issues on your board, it may be dropping bits at speed.

Reply
  • 0

    That log I think shows you're really not connected to the SWD port at all. There's a few bit sequences in there that are impossible, for instance the writes to the ABORT register may not return WAIT or FAULT, similarly reads from the CTRL/STAT register may not return WAIT or FAULT. In general there are way too many FAULTS there. Also I believe with overrun detection turned on, the stickyoverrun flag should get set by the faults and according to that trace it's not.

    What produces that trace? It's possible whatever is doing that is entirely confused and unsequenced and is decoding rubbish. Because I'm surprised you can even get the debugger connected if you have that many issues. Do you get a reasonable connection response to the initial connect on the JLink?

    You could try dropping the SWD speed down, if you have some electrical issues on your board, it may be dropping bits at speed.

Children
No Data
Related