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

Bricked Sparkfun nRF52832?

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

Parents
  • 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).

  • This looks promising! I still doubt that you would "damage" some GPIO port and it's now impossible to use UART on it. I would also be very careful to attempt writing whole FICR and UICR regions, there are only few registers which are user (app) specific, rest should be managed by the chip without interference. Is there any small chance that Sparkfun loads some diversified data so FW works only if it matches S/N of the chip (8-byte string in FICR region)? Isn't there somewhere source code to Sparkfun bootloader (or entire pre-loaded FW)?

    Another point is that Nordic tools are multiplatform but I've always used Windows tools (nRFgo Studio and NRFJPROG from NRFTOOLS package) to recover/erase and flash nRF5x chips. Alternatives like NRFUTIL and OpenOCD/pyOCD are known to behave slightly differently...

    Another one: why insisting on proprietary UART bootloader if you can use SWD programming?

Reply
  • This looks promising! I still doubt that you would "damage" some GPIO port and it's now impossible to use UART on it. I would also be very careful to attempt writing whole FICR and UICR regions, there are only few registers which are user (app) specific, rest should be managed by the chip without interference. Is there any small chance that Sparkfun loads some diversified data so FW works only if it matches S/N of the chip (8-byte string in FICR region)? Isn't there somewhere source code to Sparkfun bootloader (or entire pre-loaded FW)?

    Another point is that Nordic tools are multiplatform but I've always used Windows tools (nRFgo Studio and NRFJPROG from NRFTOOLS package) to recover/erase and flash nRF5x chips. Alternatives like NRFUTIL and OpenOCD/pyOCD are known to behave slightly differently...

    Another one: why insisting on proprietary UART bootloader if you can use SWD programming?

Children
No Data
Related