Error flashing custom board w/ nRF52832 (unable to read)

[towes]

I'm trying to flash a custom board (schematics in this ticket - Schematic/Layout review request) using a Jlink EDU mini and keep running into an error message saying it's failing to read or erase memory. I've seen suggestions on other posts that running nrfjprog --recover can remove the read protection mechanism, but when I ran that (with --log, which I've attached) it also failed.

 

4274.log.log

I've had the flash process succeed sometimes, but the board doesn't act any differently to before (can't control the GPIO) so I'm assuming that's another issue.

Any ideas for what could be causing this?

Thanks

[Simonr]

Hi

Okay, these should be fine. There was just a warning saying that an action wasn't available for engineering versions of nRF52832, so I was worried you had an old one, but that doesn't seem to be the case.

Then it falls back to that it seems to be bad contact between the J-Link and the boards, and I think you need to do some troubleshooting on the SWD lines on the nRF52 boards. One thing that would be interesting is to see if you are able to run an nrfjprog --readregs after nrfjprog --recover. If you can read out these you can also read out the RESETREAS register to see the reason for the last reset. That way we can confirm whether there's been any resets due to POR or BOR (power/voltage failures due to a voltage dip for example.

You can also try using a lower SWD CLK frequency to see if that helps, but I would definitely triple check the SWD and VDD lines on your boards to see that they are properly connected on your end.

Best regards,

Simon

[towes]

So for this action (I think it's --debugreset based on this) that's not being allowed, is there another reason why the command would fail other than being an Engineering A device? Because it should work otherwise, right?

I did try reading the registers and I don't have access to the RESETREAS register (or a lot of other ones by the look of it), so no help on that front.

For the connections to the board, I'm a bit stuck on how the Jlink can return what the chip is if there's some issue with the SWD lines, unless it reads that back in a different way than I'm aware of. That seems like pretty good proof that the IC is properly connected.

And my above thought was possibly confirmed when I tried running the same command from the log file with a --clockspeed 10 added to it. That completed with no errors (took ages though), and then same with --clockspeed 100. I then tried the "flash" through the VSCode extension, which should be the same command that failed previously and it worked. Not sure what the difference might be now, but there are also now progress bars for each step that weren't there before (Still on v10.24.2 of nrfjprog).

There are still intermittent issues with programming where it says it's unable to read memory (below), but it probably works 70% of the time now (there is a separate issue of the program seeming to stall once it gets to a delay but that seems unrelated)