Xenon bricked after Firmware update to v0.8.0-rc.26

Hi,
I upated ten Xenons to the latest FW (v0.8.0-rc.26) yesterday. Nine went well and one got bricked.
After flashing it lit up briefly and then got dark. None of the on board LEDs light up if I power it up or press one of the buttons.

I own a J-Link and have Segger Studio installed. I still can read the memory using Segger Studio / J-Link. It looks like the bootloader is corrupt.

What is the correct procedure to bring it back to life?

I found the bootloader files here https://github.com/particle-iot/firmware/releases.
To what address do I have to burn the bootloader? 0xF4000?

Thanks in advance

Yes, bootloader to 0xf4000.

If that doesn’t solve the problem, you also need to flash the softdevice. The link and instructions are here:

https://docs.particle.io/support/particle-tools-faq/jtag/#openocd-telnet-commands-3rd-generation-

1 Like

I had a similar problem when updating a boron last night. I was able to fix it by reflashing the bootloader and system firmware with openocd.

1 Like

I completely erased the Xenon and started from scratch (I used a J-Link and Segger Embedded Studio). Here’s what you need…

  1. Bootloader to 0xF4000 -> https://github.com/particle-iot/firmware/releases e.g. bootloader-0.8.0-rc.26-xenon.bin
  2. Softdevice to 0x00000 -> https://docs.particle.io/assets/files/s140_nrf52_6.0.0_softdevice.hex
  3. Firmware to 0x30000 -> https://github.com/particle-iot/firmware/releases e.g. hybrid-0.8.0-rc.26-xenon.bin

After flashing the above, it did not yet start. By comparing with the memory map of a healthy Xenon I found out that the following must be set too:

UICR User information configuration (see https://www.nordicsemi.com/DocLib/Content/Product_Spec/nRF52840/latest/uicr)
Addr = 0x10001014 -> Value = 0x000F4000 (NRFFW[n] Seems to be the start vector of the bootloader)
Addr = 0x10001200 -> Value = 0x00000012 (PSELRESET[n] Mapping of the nRESET function)
Addr = 0x10001204 -> Value = 0x00000012 (PSELRESET[n] Mapping of the nRESET function)

After that the Xenon started blinking (in blue) again and I could register it to my mesh…:wink:

@rickkas7: Could you please verify the above?

There’s a newer version of the nRF5 SDK (s140_nrf52_6.1.0_softdevice.hex) as the one you suggested.
You can find it at https://github.com/NordicSemiconductor/nRF5-SDK-for-Mesh/tree/master/bin/softdevice. I flashed it and it seems to work well…:wink:

2 Likes

If you completely erase your device (not recommended), you do need to set the bootloader address. If you have the nrf52-var.cfg file from the JTAG FAQ, there’s a macro for it:

openocd -f interface/cmsis-dap.cfg -c 'adapter_khz 1000; transport select swd' -f target/nrf52-var.cfg -c "init" -c "bld_addr 0x000F4000" -c "exit"

Program the softdevice, bootloader, system, and user firmware by SWD.

You’ll also need to reset the device keys. In DFU mode (blinking yellow):

particle keys server --protocol udp --host '$id.udp-mesh.particle.io'
particle keys doctor YOUR_DEVICE_ID
1 Like

I can't be sure if this is the exact version, but there was a regression in the (then) most recent nRF SDK that caused a delay in the release of rc.26 where Particle had to go back to a previous version in order to not introduce new issues instead of fixing known ones.

That's why Particle also flushed that respective version rather than flashing it :wink:

1 Like

@ScruffR: Hahaha, thanks for the info and the hint (fixed the typo)…:wink:
@rickkas7: Thanks for your help. Keys are up to date now too!

2 Likes

Hi, I have the very same problem (bricked Xenon) and am unable to get it up and running. The challenge is that I have a Black Magic Probe debugger that is not OpenOCD compliant. Therefore I cannot use the description in the FAQ or in this thread.
I have done the following steps:

So what I see is that none if the LEDs are lit after reset, the PC is not recognizing the device as USB periferal, and when I attach the debugger to Xenon I see that the program counter is in the softdevice memory area. When I set a breakpoint to 0xf4240, that is the first executable code of the boot loader then I see that this breakpoint is never hit.
Is there anything that I miss? Alternatively can someone please send me a full Flash dump of a working Xenon that includes both the Code Flash and the UICR Flash ranges?

Update: Eventually I got it working.
As of the writing of this post, the latest firmware is v 1.4.4. This has got my Xenon unbricked:

This combo got the device up to a certain state from which I could individually update the middleware components via USB. In case of the boot loader I had to use --force-update, because, I think, the BL has identified itself more up to date than the release binary.

The major issue was the softdevice. I suspect that the binary file in the github release folder has been adjusted (?) for the particle update process. For example it has a strange stack pointer value at address 0x0000. The original softdevice 6.1.1 from the SDK has saved the day.