Bricking core in battery application due to brown out condition

Hi,

I bricked the Spark core in my weather station because one cell of the battery died. Its a 4 cell NiCad battery connected to a step up/down converter. The converter delivers 3.3V and works down to 2.3V. Lower voltages means higher current. My assumption is, that the power starting to oscillate when the converter dropped and then the battery recovered and the converter powered up again.

Unfortunately, I can not recover the core anymore. When I supply the core with power it immediately starts breathing in cyan. No green flashing light for connecting to WiFi.

Reseting is also not possible. If I reset to the point where the LED is flashing white (to get to the blue state for setting new Wifi credentials), the core only breath cyan again. Reseting to the yellow state, my PC recognizes a unknown device named DFU CORE.

Can I recover the core somehow?

You will need to flash your device over DFU to get everything working again. Do a quick search on the forums for “DFU insert development operating system here” for several good tutorials on the process. If you run into trouble post back here and I’ll be happy to help!

I guess it didn’t kill anything since you are noy voing through the LDO.

Is it breathing white or cyan?

had a more epic case recently and I’m going to debug with a stlinkV2 when time permits :slight_smile:

If you have DFU mode available (blinking yellow) it’s super easy to get your core back to the living with the Spark CLI. In the command line you just type spark flash --usb tinker and :boom: you’re back up and running.

DFU MODE

SPARK CLI

Maybe…but if factory reset didn’t worked then…

This term in parenthesis does confuse me.
If you want to get into listening mode (blue state) you’d press and hold MODE while the Core is running, but to perform a factory reset you’d press and hold MODE plus tap RESET to get into DFU mode (yellow blinking) first, but carry on holding down MODE till you end up in FR (white).

Some good and bad news

I was able to communicate with the core with my notebook where I have installed the Spark CLI.
Installing the tinker software produced this response

C:\Users\UG>spark flash --usb tinker
FOUND DFU DEVICE 1d50:607f
checking file  C:\Users\UG\AppData\Roaming\npm\node_modules\spark-cli\binaries\s
park_tinker.bin
spawning dfu-util -d 1d50:607f -a 0 -i 0 -s 0x08005000:leave -D C:\Users\UG\AppD
ata\Roaming\npm\node_modules\spark-cli\binaries\spark_tinker.bin
dfu-util 0.7

Copyright 2005-2008 Weston Schmidt, Harald Welte and OpenMoko Inc.
Copyright 2010-2012 Tormod Volden and Stefan Schmidt
This program is Free Software and has ABSOLUTELY NO WARRANTY
Please report bugs to dfu-util@lists.gnumonks.org

Filter on vendor = 0x1d50 product = 0x607f
Opening DFU capable USB device... ID 1d50:607f
Run-time device DFU version 011a
Found DFU: [1d50:607f] devnum=0, cfg=1, intf=0, alt=0, name="@Internal Flash  /0
x08000000/20*001Ka,108*001Kg"
Claiming USB DFU Interface...
Setting Alternate Setting #0 ...
Determining device status: state = dfuERROR, status = 10
dfuERROR, clearing status
Determining device status: state = dfuIDLE, status = 0
dfuIDLE, continuing
DFU mode device DFU version 011a
Device returned transfer size 1024
No valid DFU suffix signature
Warning: File has no DFU suffix
DfuSe interface name: "Internal Flash  "
Downloading to address = 0x08005000, size = 78948
..............................................................................
File downloaded successfully
Transitioning to dfuMANIFEST state
Error during download get_status
Flashed!

Iimmediately after power up the core is breathing cyan.

2 Likes

Hi @digixx

Despite the fact that is says “Error during download get_status” the output you are showing means it correctly flashed Tinker via dfu-util.

Looks like you are back in business.

Yeah… but if I’m reading this correctly @bko, he is not seeing the blinking GREEN after powering up. It just goes straight to breathing CYAN, which sounds impossible.

@digixx could you do me a favor and verify that if your WiFi AP is OFF, when you power up your Core does it still breathe CYAN??

If so I would guess you should be able to erase the device completely and re-flash the bootloader. It’s not that bad to re-flash the bootloader, but if it’s something you’d rather not do let me know and we’ll figure something out.

I’d also be interested in what code you were running on your Core when it failed.

1 Like

Hi,

to give a quick summary

  1. Immediately after power up, the core is breathing white (I made the check with a fresh out of the box core bind to the Wifi). The bricked core shows all three colors breathing, the other only green and blue.

  2. In yellow mode, its possible to send data to the core but it does not run. (goes back to point 1.)

  3. the blue mode cannot be reached, falls back to point 1.

@BDub Yes, lets re-flash the bootloader. How does this go?

Edit: Without any Wifi, same behaviour. You can find the software running on the core at the time of bricking here

@digixx, look here for the instructions. :smiley:

I do not have a working programmer shield or an ST-link programmer.

Hi @digixx

One more thing you can try is running the TI patch over Spark CLI in DFU (yellow) mode by doing
spark flash --usb cc3000
It could be that it’s firmware is hosed too!

1 Like

doesnt help, it flashed magento after then, even with power cycle.
If I try the blue mode again, its breathing white twice a second. even after power cycle.

Hi there,

I think the best course of action here is to do a replacement for you. If you could email hello@spark.io and reference this community post, I will get that process started for you.

Regards,
Kevin @ Spark

2 Likes