Also, it sounds like you said your Electron was initially connected to USB for Serial prints, and your LiPo battery disconnected? Please be advised that most USB ports cannot handle the up to peak 2A currents that the modem requires, and will cause a brown out at the electron. To remedy this, you should keep the LiPo battery attached. Do you remember what steps took place between the time things were functioning and not? Were you reprogramming anything (dfu/ota/y-modem), and what kinds of power/flash functions were you using if any (sleep/eeprom/etc…)?
I have an electron in the field that stops working with no RGB led and a dimly lit Blue D7 LED, HOWEVER a reset is bringing this back to life at the moment.
- I have 2 of these devices running the same code and only one of them is doing this.
- There is no Lipo battery attached we are supplying the device from our own carrier board via VIN at 5V and 2A.
3, The power supply is very steady (120Ahr @ 12V) External Solar Regulator charging the batteries.
- I’m using 0.7.0-rc.3 firmware
- Sometimes it runs for 2 weeks, yesterday it ran for 7 hours.
I have a few questions.
1, If this is a user code fault, shouldn’t it blink the RGB red with the SOS, or white, or some colour, or anything other than off?
2. Has anyone seen this fault (no RGB LED, and dim D7 - recovered by a reset)
3. I have the application WDT running and it’s not resetting the device.
4. Has anyone got a nice function to see processor utilisation?
5. What does the Electron do with USB Serial printf if the USB is not connected? does it skip the section of code or still go through the process of printing it? - I wonder if I have too much serial debug slowing it down in some wierd way.
Thanks and Regards
@marshall, the “no RGB LED and dim D7 LED” is the classic indicator for a low voltage condition leading to a wiping of parts of the flash, typically the DCT area. The 0.7.0-rc.3 system firmware includes an auto-healer for this so this is why hitting reset brings it back to life.
The thing with the onboard LiPo is that it can supply high peak current for the modem. This means fast response (ie rise time) to current demand. You need to make sure your 5v regulator can supply (at least) 2 amps of current with a fast rise time. You should over-spec the regulator so it doesn’t get hot and runs well within its operating range. What regulator are your using?
The best thing you can do is setup logging on the device to get a detailed output of the system activities.
The print occurs as if the port was connected but it doesn’t go anywhere. You could qualify your prints with isConnected() so that you skip the print when a host is not connected.
Thanks for the fast reply.
Our regulator is a Active Semi ACT4060A we chose this as we are able to put a 12V Solar panel directly on it without it blowing up. the O/C voltage of a solar panel approaches 22V. (anyway we don’t use a solar panel directly in this case)
I had a quick look at the datasheet but didn’t see any demand curves vs rise time on them. I’ll put a battery on and see if that results in any improvements, its a really easy fix.
I’ll report back on the results.
I like the idea about the isConnected() function you mentioned. I have my debug out already in a function so it’s easy to add in just the one spot.
here is my debug function if anyone else wants it, it prints the line number and the function name as a prefix, then nicely aligns the message.
It takes standard printf arguments (or no arguments) so it is easy to replace existing Serial.printlnf etc with it.
#define TRACE_PORT Serial #define OPITO_DEBUG(fmt, ...) WITH_LOCK(Serial) TRACE_PORT.printlnf("%-4d:%-30s> " fmt, __LINE__, __func__, ##__VA_ARGS__);
here’s how to use it.
OPITO_DEBUG("callback rx-d %s", str);
hi bko i have same condition one of electron as you stated
what post should i follow
followed this with no luck
get same error
SWD Fault error
Please double check the wiring, then try again.
Do you have a dead device and wish to continue? [y,N]:
@viraj what is the symptom of the electron? Are the LEDs lighting up?
Do you have a dead device and wish to continue? [y,N]: after pressing on y the target electron D7 led lights solid blue, which was previously dim blue
and same error prints on hyperterminal
SWD Fault error
What happens when you attach the Lipo battery? Can you take a photo?
I have now managed to brick an electron as well
I was powering it through a lab power pack on the Vin pin and no battery. I turned the power supply off and when I turned it back on it was bricked. Seems like it was probably the slowly dropping voltage of the PSU… Maybe reproducible by just using a large cap on the Vin lines and then removing power.
I am running 0.6.0 firmware.
Could have been a power spike from turning on the power supply also.
Just checking in here to say that I also have managed to kill a few Electrons over the months by letting the battery run empty. I tried every suggested fix but couldn’t fix any of them.
By looking at the posts in this thread, the best practice to avoid this is to not allow a brownout to occur. Unfortunately, I use a LiSOCl2-battery setup which doesn’t have the typical discharge curve that a LiPo has, making the voltage level hard to monitor. Essentially, it goes from a steady 3.6V almost straight to a brownout.
I guess I may just have to accept killing a few Electrons every now and then
i have lost a few myself. i’m not an electrical engineer, but in my somewhat educated opinion i think there could be some type of voltage protection, such as a reset circuit using something like,
not so much integrated into the electron although that would be a nice gesture considering the cost of an under voltage incident to the user. but, more like something inline between the battery and the electron which in theory would just shut off power at the point voltage drops to a specific point. i have never lost an electron by just cutting power immediately such as disconnecting the usb power line with no battery attached.
This has just now happened to me again with my dev Electron, and after stuffing around trying to fix for half an hour it I read somewhere on these forums to logout/re-login from particle CLI before pushing new firmware via DFU.
That actually seemed to work for me first time I tried (with a bit of charge in that battery that is).
Could be a coincidence but thought I’d share my experience here.
Reading this thread, I’m at a crossroad in terms of deciding whether to deploy Electrons with the battery or without. My use case is trucks. The power source will be USB as the primary.
PRO: My thought is that having the battery in place provides a great second power source / backup, thus a vote FOR keeping the battery.
CON: My other thought is that if/when the customer needs to reset the Electron (it will be in an enclosure - hard to access) they simply unplug the USB which will drop power, then plug it back in. This is a vote against keeping the battery.
CON: Finally, in this thread we read that allowing the battery to completely discharge has potentially negative consequences. It will happen in the real world and I can’t have Electrons coming back that are damaged from a full battery discharge.
That’s one vote to deploy with the battery and two votes not to.
Can your power supply handle the peak current demands of the Electron? What type of Electron 2G/3G/LTE? What prevents the Electron from losing power unexpectedly (such as a vehicle battery change) (which is one of the likely causes of the corrupted device issue)? No solutions here… just more questions.
3G. Delays for 120 seconds, then makes one webhook call, and repeats… Losing power by way of pulling the USB plug out of the brick (or turning off the wall outlet off) I’m assuming has less potential for damage than allowing the battery to run dry. Is that correct?
Add some code to prevent the battery from completely discharging and some code to do a complete reset when the USB status is changed.
I had the same problem in my electron and tried out the Norwegian_Blue method. But it didn’t work out for me.
Then I followed this link exactly and my issue was resolved.
I used the ST-LINK v2. Upgraded the firmware of ST-LINK and downloaded the latest ST-Link utility.
Also, I disabled memory readout protection on ST Utility by Target menu>>Option Bytes>>Settiing readout protection to level 0.
Then I connected the device, flashed bootloader, device OS, and user firmware one by one at the respective locations and did a reset at last. Now the device was running again.
After this, I put the device DFU mode and did a particle keys doctor to set the erased keys.
Then it connected back to the cloud and came back to life.