nRF52840 DK wont turn on

[brianreinhold]

The disccussion here 

https://devzone.nordicsemi.com/f/nordic-q-a/24592/my-nrf52-nrf51-dk-kit-doesn-t-work

has been closed.

I followed step 4 and it took a few tries but I got the boot record to show as drive F on my computer. I dragged the bin file onto the drive. It started installing, drive F vanished and the power LED rapidly flashed. There were no instructions anywhere as to what to expect or what to do next. After a few minutes of waiting (and searching for documentation) I gave up and power cycled the board and it appears to work. J-Link recovered.

I was able to install a project I have. But when I try and install another project, Putty loses the serial connection and I am on the road to messing up the board again.

So the question I have, is what kind of bug could cause that issue. It has to be something simple because the code was working - but I am making changes of course. I don't know how to debug this...

Tag selection has become horrible. So I don't bother anymore.

[Simonr]

Hi

Can you provide some more details on what this project you install is? Is any SDK example causing your device to disconnect from PuTTY and "mess up the board" or is just one specific example causing this? One reason I could think of is that the UART pins are configured differently in this other project causing the PuTTY interface to disconnect. Also, what IDE are you using to build and flash your projects?

Best regards,

Simon

[brianreinhold]

I used the Segger IDE to flash the project. It had to be something I did in code because the project worked and then this happened after many code changes. Device manager in WIndows no longer showed the com port.

What I ended up doing was reverting the project (was in GIt) and that worked. After a few hours I got back to where I wanted to be and everything was good. Whatever mistake I made the first time did not repeat. Would an out-of-bounds write kill the firmware? I have made out of bounds writes before but I never crashed the board!

[Simonr]

Hi

If you overwrite I.E the UICR that can indeed cause the board to get into this state. It is not recommended to do OOB writes, as the behavior when doing so will be undefined, and may even break it to a point where a reset like this no longer works. I'm glad you got it working again.

Best regards,

Simon

[brianreinhold]

No one does OOBs on purpose! But they are bound to happen when developing new code that is working with individual bytes as one often does in transport protocols. It's scary that I can permanently brick my board doing an out of band write. I have trashed my code doing OOBs but this kind of trashing is a first!