After playing around with the Argon. I have decided to power it up with a li-po battery.
But instead of connecting to the cloud and start the code, it just keep flashing green for 3 times and once white. And of course, the Argon cannot pass beyond this point…
I have tried as well with both usb and battery. It does boot up but it turns off when the usb is unplug and goes to the blinking stage.
I have tried with another battery as well (standard 18650) and it worked fine, although sometimes it also resets with the same blinking pattern.
Lastly, I have also made sure that both batteries are around 3.9-4.1V
So, does anyone know the error code with this blinking pattern? and what could be the cause? TBH it is so weird because there is power to the MCU, but it just does not want to boot up with that specific battery?
How did you measure this?
If you measure the voltage without load (open circuit voltage) it doesn't tell you anything about the state of charge really.
Give the LiPos some time to charge before trying again.
Thanks for the reply! I measured the voltage both directly to the batteries (w/o load) and also when it was connected to the Argon. No voltage drop were observed.
I have re-measured the voltage but now with a dummy load (1st test with a 150Ohm resistor and 2nd, 47Ohm) in parallel to the Argon. The voltage drop is insignificant (0.01-0.02V)
After that, I have done a third test with an adjustable power supply set to 4V output, and still the Argon does the weird blinking.
Upon desperation, I overwrote the code that I had with blink. Updated it from OS 1.1.0 to 1.3.0. and still no success.
To double confirm that it is not the batteries. I have setup a brand new Xenon using the same battery, and it manage to setup, update and connect to the mesh without any hassle.
Based on these observations, is it possible that it is a hardware issue to my Argon?
Update:
The Argon still behave abnormally when powered on VUSB pin at 5V or 3.3V directly and Enable pulled to GND.(While the Xenon works perfectly in either configuration)
I’m afraid I don’t have much help for you, but I have a similar issue.
Using two different Adafruit Crickit FeatherWing boards with two different Argons, I have seen this same blink pattern and non-responsiveness when powering the Argon from the Crickit. I tried powering it from my laptop USB port (USB to barrel plug) and from an independent 1.5A supply. I have also verified that a Xenon seems to work perfectly fine in the Crickit.
I was trying to start with something relatively simple, based on this blog post (which also uses the Xenon instead of the Argon, but I thought they were supposed to be compatible):
If the problem is with your Argon board, then I have at least two with the same issue.
Please post if you find a cause/solution to this issue.
@Kahin, I just noticed I haven’t asked about your attached circuitry on the Argon when you see this behaviour.
Is there any? Which?
Can you also post a video?
When connected via USB source I have been able to program the Argon to read a couple of sensors and display values using components from the Grove Starter Kit; so it seems operational.
Attached is the log output from the requested tests, and a short video demonstrating the blink pattern.
Thank you for your help!
-Rob!
:~ rob$ particle flash --usb tinker -v
dfu-util 0.9
Copyright 2005-2009 Weston Schmidt, Harald Welte and OpenMoko Inc.
Copyright 2010-2016 Tormod Volden and Stefan Schmidt
This program is Free Software and has ABSOLUTELY NO WARRANTY
Please report bugs to http://sourceforge.net/p/dfu-util/tickets/
dfu-util: Invalid DFU suffix signature
dfu-util: A valid DFU suffix will be required in a future dfu-util release!!!
Deducing device DFU version from functional descriptor length
Opening DFU capable USB device...
ID ####:####
Run-time device DFU version 011a
Claiming USB DFU Interface...
Setting Alternate Setting #0 ...
Determining device status: state = dfuIDLE, status = 0
dfuIDLE, continuing
DFU mode device DFU version 011a
Device returned transfer size 4096
DfuSe interface name: "Internal Flash "
Downloading to address = 0x000d4000, size = 11972
Download [=========================] 100% 11972 bytes
Download done.
File downloaded successfully
Transitioning to dfuMANIFEST state
Flash success!
:~ rob$ particle update -v
> Your device is ready for a system update.
> This process should take about 30 seconds. Here it goes!
▌ Updating system firmware on the device...dfu-util 0.9
Copyright 2005-2009 Weston Schmidt, Harald Welte and OpenMoko Inc.
Copyright 2010-2016 Tormod Volden and Stefan Schmidt
This program is Free Software and has ABSOLUTELY NO WARRANTY
Please report bugs to http://sourceforge.net/p/dfu-util/tickets/
dfu-util: Invalid DFU suffix signature
dfu-util: A valid DFU suffix will be required in a future dfu-util release!!!
Deducing device DFU version from functional descriptor length
Opening DFU capable USB device...
ID ####:####
Run-time device DFU version 011a
Claiming USB DFU Interface...
Setting Alternate Setting #0 ...
Determining device status: state = dfuIDLE, status = 0
dfuIDLE, continuing
DFU mode device DFU version 011a
Device returned transfer size 4096
DfuSe interface name: "Internal Flash "
Downloading to address = 0x00030000, size = 630672
Downloadng syste[=========================] 100% 630672 bytes
Download done.
File downloaded successfully
▀ Updating system firmware on the device...dfu-util 0.9
Copyright 2005-2009 Weston Schmidt, Harald Welte and OpenMoko Inc.
Copyright 2010-2016 Tormod Volden and Stefan Schmidt
This program is Free Software and has ABSOLUTELY NO WARRANTY
Please report bugs to http://sourceforge.net/p/dfu-util/tickets/
dfu-util: Invalid DFU suffix signature
dfu-util: A valid DFU suffix will be required in a future dfu-util release!!!
Deducing device DFU version from functional descriptor length
Opening DFU capable USB device...
ID ####:####
Run-time device DFU version 011a
Claiming USB DFU Interface...
Setting Alternate Setting #2 ...
Determining device status: state = dfuIDLE, status = 0
dfuIDLE, continuing
DFU mode device DFU version 011a
Device returned transfer size 4096
DfuSe interface name: "External Flash "
Downloading to address = 0x80289000, size = 41756
Downloadng syste[=========================] 100% 41756 bytes
Download done.
File downloaded successfully
▐ Updating system firmware on the device...dfu-util 0.9
Copyright 2005-2009 Weston Schmidt, Harald Welte and OpenMoko Inc.
Copyright 2010-2016 Tormod Volden and Stefan Schmidt
This program is Free Software and has ABSOLUTELY NO WARRANTY
Please report bugs to http://sourceforge.net/p/dfu-util/tickets/
dfu-util: File too short for DFU suffix
dfu-util: A valid DFU suffix will be required in a future dfu-util release!!!
Deducing device DFU version from functional descriptor length
Opening DFU capable USB device...
ID ####:####
Run-time device DFU version 011a
Claiming USB DFU Interface...
Setting Alternate Setting #1 ...
Determining device status: state = dfuIDLE, status = 0
dfuIDLE, continuing
DFU mode device DFU version 011a
Device returned transfer size 4096
DfuSe interface name: "DCD Flash "
Downloading to address = 0x000006d9, size = 1
Downloadng syste[=========================] 100% 1 bytes
Download done.
File downloaded successfully
Transitioning to dfuMANIFEST state
! System firmware update successfully completed!
> Your device should now restart automatically.
:~ rob$ particle flash --usb tinker -v
dfu-util 0.9
Copyright 2005-2009 Weston Schmidt, Harald Welte and OpenMoko Inc.
Copyright 2010-2016 Tormod Volden and Stefan Schmidt
This program is Free Software and has ABSOLUTELY NO WARRANTY
Please report bugs to http://sourceforge.net/p/dfu-util/tickets/
dfu-util: Invalid DFU suffix signature
dfu-util: A valid DFU suffix will be required in a future dfu-util release!!!
Deducing device DFU version from functional descriptor length
Opening DFU capable USB device...
ID ####:####
Run-time device DFU version 011a
Claiming USB DFU Interface...
Setting Alternate Setting #0 ...
Determining device status: state = dfuIDLE, status = 0
dfuIDLE, continuing
DFU mode device DFU version 011a
Device returned transfer size 4096
DfuSe interface name: "Internal Flash "
Downloading to address = 0x000d4000, size = 11972
Download [=========================] 100% 11972 bytes
Download done.
File downloaded successfully
Transitioning to dfuMANIFEST state
Flash success!
:~ rob$ particle serial inspect
Platform: 12 - Argon
Modules
Bootloader module #0 - version 311, main location, 49152 bytes max size
Integrity: PASS
Address Range: PASS
Platform: PASS
Dependencies: PASS
System module #1 - version 1213, main location, 671744 bytes max size
Integrity: PASS
Address Range: PASS
Platform: PASS
Dependencies: PASS
Bootloader module #0 - version 311
User module #1 - version 5, main location, 131072 bytes max size
UUID: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
Integrity: PASS
Address Range: PASS
Platform: PASS
Dependencies: PASS
System module #1 - version 326
NCP module #0 - version 5, main location, 1536000 bytes max size
Integrity: PASS
Address Range: PASS
Platform: PASS
Dependencies: PASS
I had those 1.3" OLED display with SPI connection (SH1106) when I first encountered the problem. The connection from the display to the Argon is the following:
Please find attached the video of the various test (an empty sketch without anything connected; same and also with a xenon; and the oled test) Argon tests
That’s odd then, because the battery that I am using is from a high power cree led flashlight. Besides, the same happens when powered with 3.3V or 5V directly (please refer to my first reply for more details)
I have uploaded a new video of the Argon tests with power supply and an oscilloscope (with no success). In which the oscilloscope is connected to a resistor of 0.1Ohm in series to the Li+ pin so I can measure a rough current draw. On average the Argon is drawing less than 100mA and peak about 500mA for about 50ms. So I think the source of the problem does not lie on the lipo but the Argon.
No abnormal heating with usb. I would say it still has ambient temperature after 10min.
I did check the schematic when I first encountered the problem. The only thing that I came up with is that, the differences between usb connection and lipo/3.3V is that the nRF52840 is that the chip does not get a 5V signal and USB data lines are floating in the latter. So maybe for this reason the Argon thinks that there is a power fault and does not start the boot up process?
Sorry, I cannot reproduce your issue - I was using a 2000mAh LiPo pack (as sold by Particle) and connected it via two 20cm jumper wires to Li+ and GND (to introduces some extra “resistance” to mimik your setup) but still had no trouble connecting and keeping the connection alive for 5+ minutes
I guess your best way forward is to file a support ticket at support.particle.io
Make sure to reference this thread in your ticket.
I found something interesting.
If I detach the wifi antenna from the Argon and power it on, it continually blinks green (looking for internet). This isn’t terribly interesting, but at least it’s not flashing white.
So while it was on, I attached the wifi antenna and it eventually did find internet (breathing cyan). As long as I don’t power it off, it appears to be stable. I have gotten it to work a couple of times powering it on with the antenna attached, but that is uncommon.
I tried again with my other Argon/Crickit pair, and had the same results.
Just to clarify, you still get the short white before the flashing green, right?
The "flashing" white in your gif above is a single white blink which is expected after a reset and the repetetiveness of that probably comes from a permanent reset cycle.
It can only be a guess because the gif is too short to actually tell - hence the request
Just like in @Kahins videos and as seen in my gif, when the antenna is attached at power on, the light flashes white at power on, then repeats the pattern of a few green blinks and one white flash indefinitely. I don’t think you’ll get any more context out of a longer video; it repeats the same pattern forever. Argon Reset Loop
When poking at the Argon (pressing it down to make sure it was secure in the socket), I found that there were some times I got the number of green blinks between the white flash to temporarily increase (it runs slightly longer before resetting). However, the reset cycle still persists.
Finally, I found that if the antenna is NOT connected at power-on, it does not go into the reset cycle; instead it continually searches for internet (which it never finds without the antenna). If I attach the antenna while in this state, it will eventually find itself in the connected state. Argon Antenna Attached After Power-On
Indeed it is an interesting finding! I tried your method and it also “worked” temporarily. I tried to wobbled a bit the u.FL connector (connected already before powering up) while it is powered and in the reset cycle, and sometimes it does that extended blinking green before resetting. But I have to say, it happens quite randomly and not always reproducible.
Btw @HelloMyNameIsRob, have you tried it on a protoboard or directly without anything but with just some female jumper cable to the battery?
