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?
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…
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:
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
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:
I have created intel HEX files from each binaries, because Black Magic Probe is not really good with .bin files. I have applied offset 0 to softdevices, offset 00xf4000 to bootloader and offset 0x30000 to system.
I have created a small HEX file that stores 0xf4000 at address 0x100010014 (UICR NRFFW[0])
I have merged all hex files to one bulk ihex file and downloaded it to Xenon.
(in the meanwhile I have fixed a bug in the NRF52 driver of Black Magic Probe that did not erase subsequent Flash pages but the first one).
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:
softdevice 6.1.1 from the git sources: third_party/nrf5_sdk/nrf5_sdk/components/softdevice/s140/hex/s140_nrf52_6.1.1_softdevice.hex
a hex file that has placed 0xf4000 to the address 0x10001014
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.
