This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

nRF52840 / Laird BL654 Custom Board Programming Error

I'm getting errors on trying to program a custom board using the Laird BL654. 

We are verifying manufacturing results with an x-ray of a populated board tomorrow checking for voids or shorts. While we're trying to rule out any manufacturing errors on our end, I wanted to get input on these programming errors.
The two errors are visible in nRFgo Studio, nRF Connect's Programmer Tool, but also the nrfjprog command line.
The SWDIO line has activity verified with scope. 
  
nRFgo Studio:
Clicking under "nRF52 development dongles -> Segger XXXXXX"  Briefly Flashes:
And then the segger tool ejects from Windows and tries to re-mount as a drive. Recovery fails.
nRF Connect Programmer App:
Error when getting device info: Error: Error occured when open device long term. Errorcode: CouldNotOpenDevice (0x4) Lowlevel error: JLINKARM_DLL_ERROR (ffffff9a) 
Error when closing nrfjprog: Error: Error occured when close opened device. Errorcode: CouldNotOpenDevice (0x4) Lowlevel error: JLINKARM_DLL_ERROR (ffffff9a) 
I've also seen 'NOT_AVAILABLE_BECAUSE_PROTECTION' which in the documentation states that readback protection is enabled. Recovery attempts again do not work.
CMD.exe (nrfjprog 9.7.3 / JLinkARM.dll 6.22g):
 
Trying to run recover, eraseall or trying to connect throws this error:
ERROR: JLinkARM DLL reported an error. Try again. If error condition
ERROR: persists, run the same command again with argument --log, con
ERROR: Semiconductor and provide the generated log.log file to them.

Any help would be greatly appreciated,
Jeff
  • Hey Jeff,

    How many boards are affected?

    What kind of programmer are you using and what is its configuration? 

    Cheers,

    Håkon.

  • haakonsh,

    I've tested two boards. Same results. Waiting for x-ray still. 

    I've used the nRF52840 dev kit as well as Laird's BL654 dev kit. 
    Same setup as I've run successfully with the nrf52832/BL652. 

    Thanks,

    Jeff

  • Did another prototype run. X-rays look good on that, but I still am having this same problem. 
    Any help would be appreciated. Total of 7 boards affected. 

    --Jeff

  • In connecting to the nRFgo Studio programmer by way of the Nordic Development board connected to my target using the debug header, I placed an oscilloscope on the data and clock lines during the failed attempt to connect.  The following set of figures is one capture from that exchange that takes place when a connection is supposed to take place between the programmer and the BL654 on my board.  You can see the entirety of the exchange across the top of the screen which lasted about 50ms long.  The main portion of each screen is a zoomed in section of the exchange highlighted by the white bars on the top portion of the screen.
    Here are my observations: 
    1. Appears that the clock is running at around 1MHz.
    2. (see first figure below) I believe I see evidence of both the host communicating (Nordic dev kit programmer) and my board's BL654 responding as indicated by two different logic high thresholds visible in the data line.  
    3. (see second figure below) Seems that the host (Nordic dev kit) is synchronizing data reads to the rising clock edge whereas the BL654 is synchronizing its data reads to the falling clock edge.... could this be the problem?
    4. (see third and fourth figures below) Appears to be evidence of programmer and BL654 talking over top of one another.

    Figure 1-

    Figure 2-



    Figure 3-


    Figure 4-

    Again, any insight would be very much appreciated,
    Jeff

    1. Which debug port of the DK are you using, there are three; P19, P20, and P18?
    2. Have you cut SB40? If not, do it.  
    3. What are the digital IO voltage levels of the two boards?
    4. I think the lines are a bit capacitivly loaded, the SWDIO line seems to have a high rise time at certain points. Try to lower the SWDCLK frequency and see if that makes a difference. 
    5. I do not know how they could synchronize on the wrong flank, but it might be possible.
    6. Do you mind sharing schematics and layout files?
Related