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 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

  • 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.

  • Are you sure that "debug out" is really active on your nRF5x DK? There must be certain PINs shorted beside plugging all 4 or 5 wires (depending if you provide 3V3/5V power from DK board or separately). I'm using both nRF51 and nRF52 DK boards to flash custom boards with nRF51x22 chips and it works flawlessly (using nrfjprog or SEGGER J-Flash). In my case I simply connect PINs 2 and 3 on P20 header (VIO to SH_VTG).

    Cheers Jan

  • Thank you very much for your insight. I do believe I am connecting over SWD. Note the TCP/IP connection on the console output in Eclipse. Also, there are records to the debug port...which doesn't happen unless i connect. the protocol analyzer i am using is Saleae logic's..and i would agree with you...perhaps the parsing is incorrect. Connecting to J-Link... ... Target voltage: 3.30 V Listening on TCP/IP port 2331 Connecting to target...Connected to target Waiting for GDB connection...Connected to 127.0.0.1 Reading all registers Read 4 bytes @ address 0x00000000 (Data = 0x20000000) Target interface speed set to 1000 kHz Resetting target Halting target CPU... ...Target halted (PC = 0x0000048C)

  • Jan, thank you. I am able to verify debug out works. I hook up Adafruit's Bluefruit friend and am able to loadfile and debug. i assume it is something i am doing wrong on my pcb design. I want to minize...do you know what pins need to be engaged? E.g.: VDD, but not AVDD (not using radio/softdevice), SWD, SWCLK...so 4 pins on the chip are all that are needed to flash program?

  • Looking at "good" SWD traffic versus "bad" traffic, one thing that pops out are writes to the DebugPort return a FAULT from the external nRF51822. If this is the reason, perhaps the nRF51 DK (host) cannot write to Flash. Now i need to figure out how to test this by sending a write to flash within the JLINK command tool.

Related