From development kit to a real device - after flashing I cannot access my device any more...

[pilux]

Hello all.

I'm a newbie hardware person - not a newbie software developer though ;) - that's trying to go from working code on a development kit to an actual hardware board. For the DKs I have both an nRF52840DK and an nRF52DK. My code works fine on both of these. My only external hardware is a simple RS232 converter.

I have had some - five - hardware boards made up which incorporate an E73-2G4M04S1B module, with a debug header that exposes gnd/swio/swclk/3.3v. The only other connections to the module are a pair of pins towards the RS232 converter and the various grounds around the module go to ground.

Out of the box, I can connect the debug header to the device (io->io, clk->clk, gnd->gnd, vdd->+v, with the joined pins on the dev board) and it comes back with this:

C:\WINDOWS\system32>nrfjprog --deviceversion --log --family nrf52
1050212188 - NRF52832_xxAA_REV2

This is as expected. This is the 52840 dev kit and it's correctly reporting the device it's found as the nFR52832 on the module. Great.

I flash the module using VSCode using the same code that works on the nRF52 DK. Unplug it, plug it back in using exactly the same cable/etc, but now it's dead:

C:\WINDOWS\system32>nrfjprog --deviceversion --log --family nrf52
[error] [SeggerBackend] - JLinkARM.dll reported "-1", "An unknown error.".
[error] [SeggerBackend] - JLinkARM.dll reported "-1", "An unknown error.".
[error] [SeggerBackend] - JLinkARM.dll reported "-1", "An unknown error.".
[error] [SeggerBackend] - JLinkARM.dll reported "-1", "An unknown error.".
[error] [SeggerBackend] - JLinkARM.dll reported "-1", "An unknown error.".
[error] [SeggerBackend] - JLinkARM.dll reported "-1", "An unknown error.".
[error] [SeggerBackend] - JLinkARM.dll reported "-1", "An unknown error.".
[error] [SeggerBackend] - JLinkARM.dll reported "-1", "An unknown error.".
[error] [SeggerBackend] - JLinkARM.dll reported "-1", "An unknown error.".
[error] [SeggerBackend] - JLinkARM.dll reported "-1", "An unknown error.".
1050212188 - UNKNOWN
[error] [SeggerBackend] - JLinkARM.dll reported "-1", "An unknown error.".
[error] [SeggerBackend] - JLinkARM.dll reported "-1", "An unknown error.".
[error] [SeggerBackend] - JLinkARM.dll reported "-1", "An unknown error.".

... etc

 And unfortunately now I'm stuck. Trying --eraseall or --recover result in the same issues with various read fails. 

Things that might be an issue, or that I have tried:

1. I've used the DK's board and added an overlay to disable everything I didn't need. All works fine on the DK.

2. I saw posts about perhaps the reset pin being an issue with having it enabled as a reset pin on the DK while nothing is connected on my board. I have tried connecting pin 21 - the one next to clk - directly to +3.3v with no change. Out of desperation I have also tried putting it low at plug in, then high, with no change either. Before I broke the 3rd board I had enabled the CONFIG_GPIO_AS_PINRESET=n option and done a full rebuild, with the hope that the reset pin was the problem and that this would fix it. It didn't.  

3. I've checked physical connections and all seem fine. All devices behaved until I flashed them and then disappeared. I've currently got three bricked devices where I have flashed them and two untouched ones that respond to the nrfjprog with the device strings as above.

4. I had later versions of the J-Link installed but have put the software back to the 7.66a that nrfjprog mentioned. Current versions in play:

C:\WINDOWS\system32>nrfjprog -v
nrfjprog version: 10.19.0 external
JLinkARM.dll version: 7.66a

5. I have the latest of all the nrf connect sdk tools. I am using the 2.2.0 sdk. I was previously using 2.2.0-rc-1 but had issues with nanopb so upgraded.

6. As far as I can tell, my code does not run on the device post-flashing. On the DK it acts as a peripheral and I can connect to it using my phone. When standalone after the flash, nothing is available; it does have power going to the right pins but nothing seems to be happening otherwise.

7. I have tried powering my device externally (it has a 5v->3v regulator) and connecting the gnd/io/clk to the DK. Same results.

8. OS is Windows 10.

I'm new at this and hopefully I have missed something really obvious ...? I'd like to at least find the issue so I don't kill more devices, but if I can get the other devices back then that'd be great. If I've missed out any information that you need then let me know and I'll grab it.

Many thanks,

Tim.

[pilux]

Minor update. I found this as a related issue and will try modifying the software board to not be based on the DK, using the vbluno52 as a base:
NRF52832 custom board not detected after flashing zephyr program 

I don't understand comments about the crystal in the linked github issue though; both are 32MHz as far as I can see:
https://github.com/zephyrproject-rtos/zephyr/issues/25379

Of the three dead boards, two have "mostly" come back by wiring up the reset pin. The one where I set this: CONFIG_GPIO_AS_PINRESET=n is totally dead and unresponsive. "Mostly" means that the boards do identify themselves correctly but I'm getting spurious lines:

[error] [SeggerBackend] - JLinkARM.dll reported "-1", "An unknown error.".

I haven't tried re-flashing any yet as I want to have migrated the board software beforehand.

It would really help my understanding here if somebody can properly point me to the actual issue? Is it this DCDC startup that's on the DK but not the E73 board?

Many thanks,

Tim.

P.s. if anybody has an idea to resurrect the one I broke then I'm still interested. In hindsight, knocking out the reset pin seems a bit silly, as now I can't connect to it to do a software reset...? The next boards will definitely have reset tied high with a button to take it low.

[Elfving]

Hello Tim,

I believe the DK is configured to use an external LF crystal by default. vbluno52 might do so as well. 

What are you using on your custom board? You could make it use internal RC, if you do not have an external one on your custom board.

Regards,

Elfving

[pilux]

Many thanks for the reply. I was only looking at the vbluno52 because that's what the other thread said. It doesn't actually look very similar to the module I have.

Now I've looked through the board list though - and I have no idea how I missed this before - there's an "ebyte_e73_tbb_nrf52832" board that embeds the same E73-2G4M04S1B module that I have into a devkit along with a few switches/LEDs/etc.

I have switched my code to that board, again made an overlay and disabled the parts I don't need (LEDs, PWM) and redirected the uart onto my pins. Early indications are good: the board boots and now appears as my Bluetooth peripheral in my mobile app! I haven't had the time to connect it to the actual RS232 device to test the uart behaves, but it's back to looking hopeful.

I also resurrected the last dead board by running this:

nrfjprog -f NRF52 --recover

in a loop while disconnecting and reconnecting various leads on the device until it worked. Pulling ground and the clock line and putting them both back on together seemed to be the fix for me, but I'm fairly sure it's a timing thing and other pins would have worked at the right time too. I did nothing with the reset pin as this was the board that I'd disabled it on... That tip was from here (plan E!):
https://gist.github.com/cszuo/22a08e3263fcfd397bf9bd91ce5168b0

Next up I'll check the uart and go happily back into the software world for a bit!

[Elfving]

pilux said:

Now I've looked through the board list though - and I have no idea how I missed this before - there's an "ebyte_e73_tbb_nrf52832" board that embeds the same E73-2G4M04S1B module that I have into a devkit along with a few switches/LEDs/etc.

Yeah, then that sounds like a better starting point. If that works for you then I guess the clock might have been the culprit, and you could also configure the other ones to use the internal clock.

pilux said:

I also resurrected the last dead board by running this:

nrfjprog -f NRF52 --recover

in a loop while disconnecting and reconnecting various leads on the device until it worked.

Hehe thanks for letting me know, I haven't heard of this method before.

Then I guess everything essentially works for you now?

Otherwise, it could be interesting to see these errors with verbose logging enabled through the Programmer app and maybe making sure the SWD is connected correctly.

pilux said:

Next up I'll check the uart and go happily back into the software world for a bit!

Hopefully you haven't completely lost your appetite for hardware stuff after this experience. We'll be here for you when you come back.

Regards,

Elfving