Tried this on 2 different Argons.
Each argon I did a particle update using cli 2.8.2
I cleaned, compiled and reflashed an old simple app that uses SYSTEM_MODE(MANUAL) and then triggers some GPIO. The new build of OS and app were with V 2.0 rc 4 in particle workbench. Both os and app were flashed to the device.
It use to work fine with LED showing white, it now seems to start looking for wifi even though the MANUAL mode has been set as it is flashing green.
Any thoughts would be appreciated.
Yes, I believe so. They were likely on wifi at some point, but am using them without the wifi need currently.
Here is the code.
SYSTEM_MODE(MANUAL);
#include "MCP23017-RK.h"
#define MCP_RESET D6
#define BANK_0 D2
#define BANK_1 D3
#define BANK_2 D4
#define BANK_3 D5
#define MEMORY_SELECT A4
MCP23017 gpio(Wire, 1);
void setup() {
pinMode(MEMORY_SELECT, OUTPUT);
pinMode(BANK_0, OUTPUT);
pinMode(BANK_1, OUTPUT);
pinMode(BANK_2, OUTPUT);
pinMode(BANK_3, OUTPUT);
digitalWrite(BANK_0, HIGH);
digitalWrite(BANK_1, LOW);
digitalWrite(BANK_2, LOW);
digitalWrite(BANK_3, LOW);
pinMode(MCP_RESET, OUTPUT);
digitalWrite(MCP_RESET, LOW);
delay(2000);
digitalWrite(MCP_RESET, HIGH);
delay(100);
gpio.begin();
for (int i=0; i<16; i++) {
gpio.pinMode(i, OUTPUT);
}
SPI.begin(MEMORY_SELECT);
SPI.setClockSpeed(10, MHZ);
//SPI.setDataMode(SPI_MODE1);
digitalWrite(MEMORY_SELECT, LOW);
SPI.transfer(0x02);
SPI.transfer(0x00);
SPI.transfer(0x00);
SPI.transfer(0x00);
SPI.transfer(0xCA);
SPI.transfer(0xFE);
digitalWrite(MEMORY_SELECT, HIGH);
// Serial.begin(9600);
}
void loop() {
for (int i=0; i<16; i++) {
gpio.digitalWrite(i, HIGH);
}
delay(20);
// digitalWrite(MEMORY_SELECT, LOW);
// SPI.transfer(0x03);
// SPI.transfer(0x00);
// SPI.transfer(0x00);
// SPI.transfer(0x00);
// Serial.println(SPI.transfer(0x00), HEX);
// Serial.println(SPI.transfer(0x00), HEX);
// digitalWrite(MEMORY_SELECT, HIGH);
// delay(1000);
}
here
Same behavior with this simple hello world program
SYSTEM_MODE(MANUAL)
void setup() {
pinMode(D7, OUTPUT);
}
void loop() {
digitalWrite(D7, HIGH);
delay(200);
digitalWrite(D7, LOW);
delay(200);
}
I had success breathing white when running your last firmware example (blinker).
The Argon I am using for this experiment had issues loading os properly when I first received it, new, from a vendor recently. To correct things, I connected the Argon to my computer via USB cable and entered DFU mode. Then, I entered the following CLI commands:
particle flash --usb tinker -v
particle update -v
particle flash --usb tinker -v
then flashed firmware and target os without any further problems. Perhaps this may help you.
Hey @robc. Thanks so much for the suggestions. I did follow your process to the letter. The particle update -v definitely did a lot more than originally but alas, I am still getting a flashing green led after reset and after loading my simple hello world program again.
For reference, this is what was displayed during update
> 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!!!
▀ Updating system firmware on the device...Opening DFU capable USB device...
ID 2b04:d00c
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 = 635412
Downloadng syste[=========================] 100% 635412 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!!!
Opening DFU capable USB device...
ID 2b04:d00c
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 = 0x00001000, size = 153024
Downloadng syste[=========================] 100% 153024 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!!!
Opening DFU capable USB device...
ID 2b04:d00c
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 = 42028
Downloadng syste[=========================] 100% 42028 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!!!
Opening DFU capable USB device...
ID 2b04:d00c
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.
Reverting to 1.5.2 and reflashing fixed the issue so definitely something going on when using 2.0.0 rc 4. Putting 2.0.0 back on causes the issue again. I’ll submit as a bug.
Ok. I am confirming I was using os 2.0.0-rc.4 when I was running the blinker firmware and breathing white.
With the Argon in listening mode and connected by USB, could you do:
particle serial inspect
You didn’t mention flashing the bootloader. Since 2.0.0-rc.4 is not a default release, particle update will not update it, nor will workbench even in Flash application and Device OS (local) mode.
If the bootloader is not the matching version for the Device OS version, the device needs to go online to retrieve it OTA. This happens before the application runs, so whether you have SYSTEM_MODE(MANUAL) or not is irrelevant in this case, the device will always attempt to go online to retrieve this missing dependency.
Yes, I thought I flashed the new bootloader. Here is the command that I issue from the terminal.
particle flash --usb --force ~/Downloads/2.0.0-rc.4/argon/release/argon-bootloader@2.0.0-rc.4.bin
Of which is says
Flash success!
But the output from particle serial inspect clearly shows a problem
Platform: 12 - Argon
Modules
Bootloader module #0 - version 502, main location, 49152 bytes max size
Integrity: PASS
Address Range: PASS
Platform: PASS
Dependencies: PASS
System module #1 - version 1102
System module #1 - version 2007, main location, 671744 bytes max size
Integrity: PASS
Address Range: PASS
Platform: PASS
Dependencies: FAIL
Bootloader module #0 - version 1003
Radio stack module #0 - version 202
Bootloader module #0 - version 1003, main location, 131072 bytes max size
Integrity: PASS
Address Range: PASS
Platform: PASS
Dependencies: PASS
System module #1 - version 1102
NCP module #0 - version 5, main location, 1536000 bytes max size
Integrity: PASS
Address Range: PASS
Platform: PASS
Dependencies: PASS
Radio stack module #0 - version 202, main location, 192512 bytes max size
Integrity: PASS
Address Range: PASS
Platform: PASS
Dependencies: PASS
Never use the --force switch.
When the binary is suitable it will not be required.
Although it should not be necessary you can try flashing the bootloader via serial and Listening Mode
particle flash --serial <bootloader.bin>
Gotcha. When not using the force switch I get the following error.
Error writing firmware: unknown module function 2, use --force to override
This should flash appropriately to an Argon shouldn’t it?
This indicates that the binary is not suitable and --force will not change that fact.
It also appears your NCP firmware version is wrong.
From what device OS version did you upgrade to 2.0.0-rc.4?
You better flash some application firmware that doesn’t block the auto-upgrade of all relevant modules OTA or use Safe Mode.
To get back to a safe base, put the device in DFU Mode and run
particle flash --usb tinker -v
particle update -v
After that try particle serial inspect (in Listening Mode) again and see whether all FAIL results have vanished.
After that you can flash a 2.0.0-rc.4 application that also allows clout connection before go MANUAL again.
The serial method appears to have worked. Output of serial inspect is now:
Platform: 12 - Argon
Modules
Bootloader module #0 - version 1003, main location, 49152 bytes max size
Integrity: PASS
Address Range: PASS
Platform: PASS
Dependencies: PASS
System module #1 - version 1102
System module #1 - version 2007, main location, 671744 bytes max size
Integrity: PASS
Address Range: PASS
Platform: PASS
Dependencies: PASS
Bootloader module #0 - version 1003
Radio stack module #0 - version 202
Bootloader module #0 - version 1003, main location, 131072 bytes max size
Integrity: PASS
Address Range: PASS
Platform: PASS
Dependencies: PASS
System module #1 - version 1102
NCP module #0 - version 5, main location, 1536000 bytes max size
Integrity: PASS
Address Range: PASS
Platform: PASS
Dependencies: PASS
Radio stack module #0 - version 202, main location, 192512 bytes max size
Integrity: PASS
Address Range: PASS
Platform: PASS
Dependencies: PASS
And refreshing my application it is now working correctly. Thanks @ScruffR for the guidance
I’m not sure what the total moral of the story is however.
I get the first part. Don't use --force when flashing via usb the new boot loader if there is an error, however, are we also saying that particle flash serial <booloader> is more reliable than putting into DFU mode and flashing that way?
In older deviceOS versions --serial was the only way to update the bootloader.
Once you safely got to a device OS version (including bootloader) that also unlocked the --usb option both should be fine.