Bricked Sparkfun nRF52832?

[cswanson420]

I have the nRF52DK board and I am using that to reprogram the Sparkfun breakout. However, initially, I was using the Sparkfun Beefy UART device to flash the nRF52832 to begin my SPI project using BLE.

What happened: Firstly, I did something dumb.

Not getting the SPI example to work on the breakout board, I started diminishing the example's main loop to toggle an LED. This, of course, was being done at 3:30AM and I connected the LED to pin 8 and then the board can not be flashed.

In fact, the board does not acknowledge the initial transmission from the nrfutil.py utility.

Onto the nRF52 DK:

I can read the memory on the affected breakout board using the pin 19 interface of the evaluation board. I can erase the memory and write new memory. I even went so far to purchase another breakout board, savebin 512KB of working flash memeory and loadbin this file onto the affected board:

Nothing.

Failed to upgrade target. Error is: No data received on serial port. Not able to proceed.

Possible causes:

• bootloader, SoftDevice or application on target does not match the requirements in the DFU package.
• baud rate or flow control is not the same as in the target bootloader.
• target is not in DFU mode. If using the SDK examples, press Button 4 and RESET and release both to enter DFU mode.

Question:

Is there a low level checksum I can obtain that would indicate whether the board has a hardware failure?

Is the board truly bricked or can it be jump started somehow - like setting a PC register?

Is there a known flash bin file that will do some HelloWorld dance?

Destination green recycle?

Thanks

[endnode]

Hi, have you checked similar questions on the forum, e.g. this one? It's almost impossible to completely "brick" nRF5x chips, they should always be able to "recover" through Nordic tools like nRFgo Studio or nrfjprog with JTAG/SWD programmer (e.g. any Nordic nRF5x DK with SEGGER J-Link on board).

[cswanson420]

Yes, this is the article that lead me to programming the breakout board with the nRF52 DK.

I am not clear on the layout of the MBR or the starting sequence of the nRF52832 device. I have the supporting documentation from the SDK, but that seems to rely on a deeper level of understanding regarding such things as UICR.BOOT_ADR. I must be missing these things.

I can see from J-Link Commander that the system seems to stop when PC = 0x0001B07A. I can reset, go and halt from the J-Link Commander so the system is responsive. I only made a 512KB file from the good device and flashed this to the malfunctioning device. Should I make a larger file? Also, am I wrong in thinking that copying the entire flash memory from a good device will not "restore" a malfunctioning device?

[cswanson420]

So, I just tried the step command 's' and it device may be stuck in a loop.

s

0001B07A: FD E7 B #-0x06

s

0001B078: 20 BF WFE

repeat...

Looks like a branch command, but not sure what WFE is. (Wait for event?)

[endnode]

Yes, WFE is wait for event, standard command in main loop of BLE app which runs on top of Nordic stack (aka Soft Device).

If you "dump" full memory of 512kB into HEX and flash it to another nRF52 device (which has the same PCB layout and BOM) then it should work the same after reset. So this is strange... What exactly you run on the boards (FW) and what do you expect from it (aka what do you mean by "works well" vs. "is bricked")?

[endnode]

But actually you are right, there might be some UICR register values needed as well (if FW running on Sparkfun board uses it for storing some bootloader information or similar). You can dump UICR as well (at address 0x10001000, 0x210 bytes should be enough but maybe it will give you up to 4kB of data) and analyze it by using nRF52832 Product Specification (to filter "default" values from something what Sparkfun FW uses). I would assume that if certain FW needs some values in UICR it would have default values hardcoded and writes it to particular UICR registers if it detects them "empty" during boot sequence but developers of FW you are using might see it differently...