RAK4260 bricked

Was working with the RAK4260 breakout board for the past week. Programming it via ATMEL ICE in Atmel Studio.

While working, i tried to upload a different .elf file from one of the platform io ports. After this, my chip does not respond.

I can no longer read my Device Signature in Atmel studio. It reads the target voltage, but not the device It seems i have bricked the chip, and there is no way to erase the chip again. Kindly help.

I have tried with another 4260 module, and it works.


2020-11-15 20_19_09-Atmel-ICE (J42700010852) - Device Programming|635x500


I am afraid that if the device is no longer responding on the SWD interface it is bricked beyond repair.

okay… that’s bad!
any precautions to be taken to avoid a repeat of this?

It may be worth a little more persistence, trying something like OpenOCD that may give more precise control, etc.

Often times with ARM MCU’s in general what a wrong firmware load does is re-purpose SWD pins as GPIO, or enter one of various security lock modes. Sometimes the right manipulation of the hardware reset in combination with SWD commands can let you trigger an erase or unlock flash or at least halt the CPU before it starts executing the bad code, and thus get things back to a clean state where you can connect and upload good code.

Of course double check wiring. You might also see if power supply current is reasonable, or if the device is heating up, as issues there could indicate a permanent failure.

Just the other day I bricked my RAK4260 as well (at least I thought so). It was not responding on the SWD interface to the DAPLink adapter.

Following procedure brought my RAK4260 back.
I used a Segger J-Link and connected SWDIO, SWDCLK, Vref, GND AND the nReset lines to the RAK4260.
Then I could connect from the J-Link to the RAK4260. But flashing still didn’t work until I erased the complete Flash with the J-Link. After that the RAK4260 could be flashed with the original firmware.
And it is working again.

I tried the same procedure with the DAPLink adapter, but it did unfortunately not work.

It’s not uncommon for SWD setups to be configured to command a reset through the SWD protocol rather than drive the reset line, even though the user may be carefully making that electrical connection each time. This tends not to be noticed until getting into a situation where only an actual reset, and not a commanded reset would work.

Of course it could be something else.

thats good to hear…

I was using the ATMEL ICE, the same setup as yours did not work. Will try with J-link…

As a matter of interest what software did you use to drive the J-Link?