Digistump Forums
The Oak by Digistump => Oak Support => Topic started by: exeng on August 09, 2016, 12:32:16 am
-
Has anyone definitively solved or can explain the following error during upload.
Sending file to cloud, to flash OAK_GD (Device ID: d9XXXXXXXXXXXXXXXXXXXX)
Error : An error occurred while flashing the device:
Recently decided to update to 1.0.5 repo and did a factory restore and firmware update via the normal instructions. At the 3 blink state but cannot upload any sketches. Consistently see the prior quoted error message. Oak is claimed and viable on Particle.io and selected for flash via CLI.
I'm about to rip my hair out and wished I never decided to update. My Oak was running just fine for months before this.
Sorry if this has been previously discussed but I didn't see that anyone solved this... just that it went away. So far not for me.
-
This is getting weird... think you're the second or third person to have this problem. Although, since yours is still in the triple-blink state, it seems like yours is at least claiming it's waiting to be programmed, so that sounds more like the state that kh's was in.
Did you do the OakRestore OTA style update, or did you manually flash the latest firmware on? Does Particle say it's online/in config mode with no user rom?
-
Pete,
Installed 1.0.5
Did the restore to factory via my FTDI friend.
Then did the OTA Soft AP update to get to the 3 blink state and device claimed.
As describe, can't load a sketch.
Particle shows it active in the device screen but I don't see it come online in the log when connected. So frustrating. I haven't messed with my Oaks for quite awhile and wanted to get to 1.0.5 since by all indications (i.e. forum) it seemed stable.
I have one new Oak that I may that hasn't been ever configured. Maybe it's time to try bringing it into the fold. I'm very reluctant to touch any of my other Oaks that running just fine at 1.0.0.
exeng (feeling like a noob again)
-
...so that sounds more like the state that kh's was in.
Yes, it does sound like this.
I just checked all of my Oaks and found they are currently working fine. Last time this happened, it affected a few people simultaneously. We don't seem to have this situation yet, but perhaps you're just the first unlucky one this time exeng. My gut feeling is that this issue is separate to the problems fixed in 1.0.3 to 1.0.5 and we haven't gotten to the bottom of it yet.
Probably the best confirmation that this is the issue is to serial upload the OakSystem sketch with DEBUG_SETUP defined. The serial debug messages will show whether the Oak is successfully handshaking with the Particle Cloud.
To do this, follow steps 4-10 in my post here (https://digistump.com/board/index.php/topic,2306.msg10783.html#msg10783), but also define DEBUG_SETUP and make the change on line 128 of OakSystem.ino described in this post (https://digistump.com/board/index.php/topic,2277.msg10715.html#msg10715). Afterwards, to go back to the release firmware, follow the forced serial update (http://digistump.com/wiki/oak/tutorials/serialupdate) procedure.
(Don't compile a user sketch with DEBUG_SETUP defined as it will cause a fatal exception. I haven't found the cause of this yet).
-
Well it's like a nightmare... It just keeps getting worse.
Did the restore again and OTA firmware update (1.0.5). Device ID looks good. System version 10. Can see it on my wireless net and connect to it. At 3 blinking state but both OakCLI and Particle do not see it and cannot manual claim.
So frustrating.
kh, was typing when you posted. Thanks. I will try your suggestion if I can manage it.
-
OK trying the OakSystem sketch install steps but down a rat hole with respect to Python. I've not used nor am I Python savvy so bare with me.
Installed Python 2.7 but when trying to do the OakSystem upload step I get the following message:
File "C:\Users\Stephen\AppData\Roaming\Arduino15\packages\digistump\hardware\oak\1.0.5/tools//esptool.py", line 22, in <module>
import serial
ImportError: No module named serial
I'll try to figure it out as I would prefer to understand it but any guidance would help.
-
Python error fixed. Just needed to install the python serial package:
https://pypi.python.org/pypi/pyserial/2.7
Looks like I now have OakSystem per kh's instruction... On to the next step.
-
OK couldn't get any output after installing the OakSystem via serial. Mostly likely my misunderstanding of the steps required. However, in the process I learned that one can update over serial and I uploaded a sketch that was previously running just fine on this Oak that wirelessly speaks to Thinkspeak, Particle, and Blynk. Particle looks like a bust at this point and it was never critical to my app; just a curiousity. Haven't verified Bylnk yet but Thinkspeak is working just fine. Now that I know I can serial upload sketches I'm right on the edge of bailing on Particle OTA. If my Blynk functions work, that might be the nail in the coffin. I don't need the Particle headache right now. Two days, spent trying to figure out why it broke. But there is a very big part of me that wants to know why and would like it to work.
OakCLI and Particle don't see this Oak but yet my sketch can get to Thingspeak and I can see the Oak as a client it on my router.
Arrrgggh!
-
Update: Well did another restore and OTA of the latest firmware fully intending to do only serial uploads from now until the issue with "error occurred while flashing the device" is understood and/or resolved. And low and behold, OakCLI and Particle can see the Oak and it is claimed. And yet I still cannot upload a sketch. What a circus! So frustrating not knowing what gremlins are causing this very unstable unrepeatable behavior.
So... I wonder is Particle will see events from this Oak if I load my sketch via serial?
-
Sorry, I know this is very frustrating.
So... I wonder is Particle will see events from this Oak if I load my sketch via serial?
This is a great way to confirm the source of your problem. Send an event and then print a message to the serial port or blink the led to confirm it's sent. If it doesn't show up on the Particle Console or OakTerm, then it's pretty clear the Particle Cloud is not passing on your events, which is the problem I and others had. You can see the bare minimum test sketches I used for this in my post (https://community.particle.io/t/anyone-else-not-seeing-events-from-their-devices/21854/21?u=kh90909) on the Particle forums.
Also, here are some thoughts on your previous message, if you still need to get the serial debug messages working...
OK couldn't get any output after installing the OakSystem via serial.
Since you're successfully uploading sketches via serial, you must have almost everything right. Here are a few things to check...
- Make sure you edit particle_globals.h to uncomment the #define OAK_SYSTEM_ROM... and #define DEBUG_SETUP, and also comment out line 128 of OakSystem.ino (Serial.println("LOOP")) before compiling and uploading the sketch via the Arduino IDE.
- Also, before uploading the sketch, make sure you rerun the "python esptool.py ..." step 7 here (https://digistump.com/board/index.php/topic,2306.msg10783.html#msg10783). Serial upload always uploads to the first ROM slot, but if you do cloud uploads, it may upload to other slots and make those the boot default.
- After uploading, open the Arduino IDE serial monitor and set the baud rate to 115200. Then power cycle your Oak to restart the sketch (it doesn't restart automatically upon opening the serial monitor like it does for a traditional Arduino). You should see the LED triple blinking (3 fast blinks, pause, repeat) indicating the Oak is in config mode. Even if you don't have the debug messages correctly turned on, you should still see a few lines printed from the OakBoot bootloader.
- If you still don't see anything, set the baud rate in the serial monitor to 74880 and power cycle again. At this baud rate, you should see the initial boot message from the ESP8266's internal bootloader, which should look something like "ets Jan 8 2013,rst cause:2, boot mode:(1,7)" (the numbers may be different). If you don't see this, you must have an error with your FTDI connections, but that's very unlikely since you've been able to upload sketches.
OakCLI and Particle don't see this Oak but yet my sketch can get to Thingspeak and I can see the Oak as a client it on my router.
Just to clarify here...OakCLI communicates with your Oak via the Particle Cloud, so if Particle doesn't work, neither will OakCLI.
-
kh, Thanks for sticking in there with me.
I feel like I'm chasing a moving target. I don't want to give up (not my nature) but this is beating me to a pulp. Too squishy and constantly changing behavior is the problem. Repeatable behavior is easier when debugging. It could be me thrashing but I'm trying to be somewhat methodical. There has got to be some simple stupid bug somewhere but when you are coming at it as black box it's difficult to figure out.
OK enough venting. I need to set it aside for now and come back fresh to try your latest suggestions. Thanks for the info and insights. They are not lost on me yet.
The whole motivation for updating to 1.0.5 was that I was not seeing Particle updates (events) anymore and I knew that Bylnk had moved on, so I wanted to bring everything up to the latest revs.
1.0.0 was working just fine for me OTA updates and all before this.
Thanks,
exeng
-
So... I wonder is Particle will see events from this Oak if I load my sketch via serial?
If I understand your question to mean 'will Particle see events from an Oak if the sketch is loaded via serial?', then then answer should be yes. I just uploaded a sketch to my test subject after a quick forced firmware update (I really can't be bothered with OTA updating until that stabilises some more), as that resets things the same way anyway. It output the serial debug messages, and also published an event to Particle. I've included the code used below. If you're wondering why I use 74880 baud rate for Serial, it is because the bootloader uses the baud rate, so I might as well use that baud rate so I don't get garbage every time the Oak starts.
//defined back to front on the Oak
#define LED_BUILTIN BUILTIN_LED
// the setup function runs once when you press reset or power the board
void setup()
{
Serial.begin(74880);
Serial.println("Sketch starting: Blink v0.3");
Particle.publish("oak/userrom/startup","Blink v0.3", 60, PRIVATE);
// initialise digital pin 1 as an output.
pinMode(LED_BUILTIN, OUTPUT);
}
// the loop function runs over and over again forever
void loop()
{
digitalWrite(LED_BUILTIN, HIGH); // turn the LED on (HIGH is the voltage level)
delay(500); // wait for a second
digitalWrite(LED_BUILTIN, LOW); // turn the LED off by making the voltage LOW
delay(500); // wait for a second
}
-
Pete, kh thanks.
It's a new day. I'm going to "Carpe Diem" and deal with this later (i.e. evening PST).
BTW, does anyone know where the "Error: An error occurred while flashing the device" message emanates from? Perhaps that would provide a clue...or not.
exeng
-
BTW, does anyone know where the "Error: An error occurred while flashing the device" message emanates from? Perhaps that would provide a clue...or not.
exeng
It comes from OakCLI (see here (https://github.com/digistump/OakCLI/blob/master/oak.js#L148)). This error is printed if OakCLI receives an error from the SparkJS API "flash" call to program the device (Particle was formerly known as Spark, and their Cloud API was named SparkJS). Essentially, OakCLI is just relaying that it got an error from the Particle Cloud after sending it the compiled firmware image to program onto the Oak. It only tells us success/failure, no more detail about the error is provided.
-
kh, Ran through your suggested (4-10) steps again. After completing the OakSystem serial upload this is what I see on the serial monitor...
WIFI CONNECTED
PARTICLE CONNECT
AUTO CONNECT
START HANDSHAKE
SHAKE
4
BLRECV
40
SHAKE1
4
SHAKE2
BLSEND
256
0
SHAKE3
SHAKE4
BLRECV
SET KEY
SEND HELLO
GET HELLO RESPONSE
BLSEND
18
0
WAIT FOR SERVER HELLO
HRM1
BLRECV
HM1
0
Hanshake: completed
END HANDSHAKE
SEND EVENTS
BLSEND
50
0
BLSEND
50
0
SEND SUBS
BLSEND
18
0
BLSEND
18
0
SEND TIME REQ
BLSEND
18
0
LOOP
HRM1
BLRECV
HM1
13
HRM1
BLRECV
HM1
13
HRM1
BLRECV
HM1
13
HRM1
BLRECV
HM1
13
HRM1
BLRECV
HM1
12
END AUTO CONNECT
BLSEND
50
0
BLSEND
50
0
AP ONLINE
START AP
STARTED
GOTO LOOP
HRM1
BLRECV
HM1
13
HRM1
BLRECV
HM1
13
HRM1
BLRECV
HM1
1
BLSEND
226
0
BLSEND
34
0
BLSEND
18
0
HRM1
BLRECV
HM1
13
BLSEND
18
0
HRM1
BLRECV
HM1
13... and so on
Oak is at 3 blink state.
Then I comment out #define OAK_SYSTEM_ROM_4F616B 82 and switch OTA of a blink test sketch. OTA upload fails as before. No new serial output (expect a refresh that blanks the serial monitor). 3 blink state remains. Serial output continues with the BLSEND pattern.
Particle.io does seem to see the Oak. At least according to the flashing dot on the devices screen.
So I'm still left wondering why I can't do an OTA upload. Wished I could see the exchange with Particle.
-
OK, Still not able to do an OTA upload with Particle. So I did a serial upload of my very functional sketch that does Particle.publish, sends data to Thingspeak and is now again functional with Blynk (do to the 1.0.5 update). All works expect Particle stuff.
So for now I'll put this Oak back in service and pull out my last and only virgin Oak to see if I can get it operational doing the normal digistump instructions. We'll see how that goes.
Not going to touch and of my other Oaks until this is sorted.
kh, Did the serial output shed any light?
I'll post the result of trying to bring up a new Oak.
So in the worst case scenario I can serial load the OakSystem without debug and just resort to serial loads of my sketches... correct?
exeng
-
Since I have a repeatable failing OTA Oak, I'm wondering if further debug output from particle_core.cpp would help provide some clues? I'm tempted but really know where to start.
-
I don't profess to have any knowledge at all of what most of the output from the debug mode means, but for comparison, here is the output from has been a working Oak when re-flashed in debug mode as kh instructed. For easier side-by-side comparision of the two, have a look at the attached comparison report.
For the most part, they are essentially the same. They both seem to claim that they have successfully connected and hand-shaked. I suspect most the later differences are simply due to me leaving a bit more of the repeated (heartbeat related?) code in the snapshot. I power cycled it three times. I got the exact same output twice, but one time I got an "UPDATE ERROR; SHAKE LOOP FAIL; END AUTO CONNECT; NO CONNECT" message, and then it looks like it did the hand-shake again, so I presume it dropped the connection or had a momentary hissy fit, as it had already successfully handshaked. Anyway, here is the repeatable output from mine.
WIFI CONNECT
WIFI CONNECTED
PARTICLE CONNECT
AUTO CONNECT
START HANDSHAKE
SHAKE
4
BLRECV
40
SHAKE1
4
SHAKE2
BLSEND
256
0
SHAKE3
SHAKE4
BLRECV
SET KEY
SEND HELLO
GET HELLO RESPONSE
BLSEND
18
0
WAIT FOR SERVER HELLO
HRM1
BLRECV
HM1
0
Hanshake: completed
END HANDSHAKE
SEND EVENTS
BLSEND
50
0
BLSEND
50
0
SEND SUBS
BLSEND
18
0
BLSEND
18
0
SEND TIME REQ
BLSEND
0
5
LOOP
HRM1
BLRECV
HM1
13
HRM1
BLRECV
HM1
13
HRM1
BLRECV
HM1
13
HRM1
BLRECV
HM1
13
HRM1
BLRECV
HM1
1
BLSEND
244
5
BLSEND
34
0
END AUTO CONNECT
HRM1
BLRECV
HM1
12
BLSEND
50
0
BLSEND
50
0
AP ONLINE
START AP
STARTED
GOTO LOOP
HRM1
BLRECV
HM1
13
HRM1
BLRECV
HM1
8
HRM1
BLRECV
HM1
13
HRM1
BLRECV
HM1
8
BLSEND
18
0
HRM1
BLRECV
HM1
13
BLSEND
18
0
HRM1
BLRECV
HM1
13
BLSEND
18
0
HRM1
BLRECV
HM1
13
BLSEND
18
0
HRM1
BLRECV
HM1
13
BLSEND
18
0
HRM1
BLRECV
HM1
13
BLSEND
18
0
HRM1
BLRECV
HM1
13
BLSEND
18
0
HRM1
BLRECV
HM1
13
BLSEND
18
0
HRM1
BLRECV
HM1
13
BLSEND
18
0
HRM1
BLRECV
HM1
13
-
And from the same Oak, after commenting out #define OAK_SYSTEM_ROM_4F616B 82 and switching to OTA programming, this is what I got (it programmed and rebooted into the user rom without any issues.
I had to attach the output from the OTA programming as it was too long for a forum post.
I then get the following from the user rom program (my sketch) - basically that repeating (heartbeat?) output.
OakBoot v1 - N,BP,4
Sketch starting: Blink v0.3 <-- output from my sketch
BLSEND
50
0
HRM1
BLRECV
HM1
13
HRM1
BLRECV
HM1
8
BLSEND
18
0
HRM1
BLRECV
HM1
13
-
kh, Did the serial output shed any light?
Sorry, I'm only getting a chance to look at this now. Nice job deciphering my instructions to get the serial debug log. It confirms that your Oak is handshaking with the Particle Cloud just fine. This is exactly the issue I had. The Particle Cloud is acknowledging the handshake, but for whatever reason, doesn't forward any events from the Oak or generate any system events for it (e.g. spark/status online).
This has proved a very difficult problem to debug because it only seems to affect the Oak (i.e. not any of the Particle devices - Core/Photon/Electron), and only a handful at a time. The Oak doesn't share the same firmware with the Core/Photon/Electron, so I suspect that either the Oak doesn't behave exactly to spec in it's interactions with the Particle Cloud, or the Cloud itself doesn't behave exactly to spec, in such a way that the Oak triggers some edge case bug that the Core/Photon/Electron don't.
More than likely, the problem will spontaneously resolve for you after some time (days to weeks - if you don't toss it out the window first :) ), as it has for all the other reported cases.
Since I have a repeatable failing OTA Oak, I'm wondering if further debug output from particle_core.cpp would help provide some clues?
It would definitely be helpful to post on the Particle forum so they're aware that this issue is still ongoing. See my post (https://digistump.com/board/index.php/topic,2330.msg10914.html#msg10914) for links to the Particle forum threads discussing this, or feel free to create your own thread. I have supplied the Particle staff with similar serial debug logs from my Oak and corresponding packet captures, but since the problem spontaneously went away, I think they hoped it was fixed by the Oak 1.0.5 firmware changes.
-
Pete, Thanks. Never see any debug output that suggests firmware is being OTA loaded like in your attached file.
kh, Thanks for all the help. I would like to help get to the bottom of this. Still want to bring the new Oak up first to see what happens with the latest release and tool chain. After that, I may play with debug mods to particle_core to try and gain some insight as to what the issue may be with my failing Oak. At least it's back online sans Particle.
kh, you and Pete are light years ahead of me in understanding the Oak / Particle internals. Thank you both for that. I'm still skimming on the surface with the occasional deep dive but only when force to dive deeper. Glad you guys are around and contributing.
exeng
-
Created a custom version of OakCLI to try to get some additional info on why the flashing error. See the code fragment below...
device.flash([onlyFile], function(err, data) {
if (err || (data && data.ok == false)) {
console.log('Error flashing: err=' + err + 'Data=' + data + 'DATA.OK=' + data.ok); // Debug
errorAndQuit('An error occurred while flashing the device:');As you can see I try to see what was coming back from Particle. At least I assume its a callback from Particle. I'm by no means fluent in .js so this was a brut force attempt.
What was returned for err was 'null' and 'false' for data.ok. Guessin the data.ok false is what caused the OTA upload bail. Unfortunately that's all I got because when I tried to add some additional debug to oak.js I got into a big fight with the build environment and eventually gave up as I'm also not well versed in the MS build tools / environment. Wanted to see the filename and path that was to be uploaded.
So with this little bit of info, does it shed any light on what may be happening between OakCLI and Particle?
-
So with this little bit of info, does it shed any light on what may be happening between OakCLI and Particle?
Unfortunately, not much. The fact that err is null means that OakCLI got a response from the API call to the Particle Cloud, but ok=false says the Particle Cloud is telling us the flash was not successful. Did the data object have any other properties? From this post (https://community.particle.io/t/help-with-firmware-update/17095) on the Particle forums, it looks like there should be a data.errors property with a more descriptive error message, but there's no documentation, so it's not clear whether data.errors is returned in every case.
-
kh, Unfortunately I was only able to build the custom OakCLI once after installing node.js and Visual Studio C++ build tools and only sent err and data.ok to the console on the first version. Wasn't aware of other objects. When I tried to build again with some additional debug output I was getting an error when building...
error MSB4126: The specified solution configuration "Release|x86" is invalid.
The successful build must have added or changed something in the build environment which caused the next build to fail. Being a complete noob with the build environment, I spent hours trying to figure out why after the first build it complained about this and couldn't find a way to fix it. Out of frustration I gave up trying to build another custom OakCLI.
Thanks for the reference to the other objects. If I get the energy to try again (perhaps after figuring out how to fix the MSB3126) I'll try to output more info from OakCLI.
-
The saga continues...
Managed to get over the build issues with MSBuild environment (stupid bat file setting of Platform had to be changed to blank for whatever reason), but I digress.
Here is the OakCLI changes (fragment). My additions are the ones with // Debug comments:
console.log('Sending file to cloud, to flash ' + config.devices[activeDeviceIndex].device_name + ' (Device ID: ' + config.devices[activeDeviceIndex].device_id + ')');
console.log('Get ready to flash ' + onlyPath + onlyFile); // Debug
device.flash([onlyFile], function(err, data) {
if (err || (data && data.ok == false)) {
console.log('Error flashing: err=' + err + 'DATA.OK=' + data.ok); // Debug
console.log('Error flashing: CODE=' + data.code); // Debug
console.log('Error flashing: ERRORS=' + data.errors); // Debug
console.log('Error flashing: ID=' + data.id); // Debug
console.log('Error flashing: STATUS=' + data.status); // Debug
errorAndQuit('An error occurred while flashing the device:');
Anxious to try the OTA upload again on my failing Oak. For good measure I...
1. Did Factory Reset
2. SoftAP firmware update
3. Using repo 1.0.5
Active on my router and claimed and connected to Particle.
http://192.168.1.70/device-id : {"id":"d9removed for public consumption","c":1}
http://192.168.1.70/system-version : 10
http://192.168.1.70/version : {"v":1}
http://192.168.1.70/particle : Connected
Upload output:
Sketch uses 264,974 bytes (25%) of program storage space. Maximum is 1,040,368 bytes.
Global variables use 52,340 bytes (63%) of dynamic memory, leaving 29,580 bytes for local variables. Maximum is 81,920 bytes.
OakCLI tool version 1.0.2
Using config file at: C:\Users\Stephen\AppData\Roaming\oak\config.json
Sending file to cloud, to flash OAK_GD (Device ID: d9removed for public consumption)
Get ready to flash C:\Users\Stephen\AppData\Local\Temp\build8772214570984903817.tmpBlinkTestPgm.cpp.bin
Error flashing: err=nullDATA.OK=false
Error flashing: CODE=200
Error flashing: ERRORS=[object Object]
Error flashing: ID=undefined
Error flashing: STATUS=undefined
Error : An error occurred while flashing the device:
the selected serial port does not exist or your board is not connected
Since I don't know the structure data,I don't know if there is any other detail to be gained from ERRORS.
Don't understand where the final message is coming from and but it seems to think my board is not connected. Didn't see this message in OakCLI. I think the final message from OakCLI is the "An error occurred while flashing the device:" so the last bit may be just a generic message do the to failed upload. From where, who knows.
At least I can build custom OakCLIs. Any suggestions while this Oak continues to fail?
exeng
-
Since I don't know the structure data,I don't know if there is any other detail to be gained from ERRORS.
If you do "console.log(data.errors);", it should print the contents of that object. In fact, "console.log(data);" should hopefully dump the entire data object.
The difference here is with console.log("String" + object) you are converting the object to a string and then logging that string to the console, whereas with console.log(object), you are logging the object itself. The console.log function is smart and prints the contents of the object.
the selected serial port does not exist or your board is not connected
Not sure where this error is coming from. I suspect it may be from the Arduino IDE after OakCLI terminates. Perhaps there is something slightly different with your build options that makes it behave differently. I'm fairly confident this isn't related to your Particle Cloud problems as it happens after the flash failed.
-
kh, Thanks for the clarification. As I said .js is new for me. I come from the old days, hence the ex in exeng. Still have my well used copyright 1978 of Kernighan and Ritchie C Programming Language book. And that's not the start of it. Fortran, punch cards, time share, Pascal, PL1, Assembly, DOS, Basic on and Apple II used to control a stack sampling probe in a 60MW power plant in the late 70's, Unix internals, Networking firmware... I digress again.
Let me see if I can get more info.
exeng
-
Here is the latest after adding additional debug to OakCLI...
The changes again: console.log('Get ready to flash ' + onlyPath + onlyFile); // Debug
device.flash([onlyFile], function(err, data) {
if (err || (data && data.ok == false)) {
console.log(data); // Debug
console.log(data.errors) // Debug
console.log('Error flashing: err=' + err + 'DATA.OK=' + data.ok); // Debug
console.log('Error flashing: CODE=' + data.code); // Debug
console.log('Error flashing: ERRORS=' + data.errors); // Debug
console.log('Error flashing: ID=' + data.id); // Debug
console.log('Error flashing: STATUS=' + data.status); // Debug
errorAndQuit('An error occurred while flashing the device:');
The test sketch based on Pete's test blink sketch...
//defined back to front on the Oak
#define LED_BUILTIN BUILTIN_LED
// the setup function runs once when you press reset or power the board
void setup()
{
Serial.begin(115200);
Serial.println("Sketch starting: Blink v0.3");
Particle.publish("oak/userrom/startup","Blink v0.3", 60, PRIVATE);
// initialise digital pin 1 as an output.
pinMode(LED_BUILTIN, OUTPUT);
}
// the loop function runs over and over again forever
void loop()
{
digitalWrite(LED_BUILTIN, HIGH); // turn the LED on (HIGH is the voltage level)
Serial.println("LED HIGH");
delay(3000); // wait for a second
digitalWrite(LED_BUILTIN, LOW); // turn the LED off by making the voltage LOW
delay(500); // wait for a second
}
The result...Sketch uses 264,974 bytes (25%) of program storage space. Maximum is 1,040,368 bytes.
Global variables use 52,340 bytes (63%) of dynamic memory, leaving 29,580 bytes for local variables. Maximum is 81,920 bytes.
OakCLI tool version 1.0.2
Using config file at: C:\Users\Stephen\AppData\Roaming\oak\config.json
Sending file to cloud, to flash OAK_GD (Device ID: d9Removed for public consumption)
Get ready to flash C:\Users\Stephen\AppData\Local\Temp\build6816829742918824593.tmpBlinkTestPgm.cpp.bin
{ ok: false,
code: 200,
errors:
[ { id: 'd9Removed for public consumption',
status: 'Update failed - File was too big!' } ] }
[ { id: 'd9Removed for public consumption',
status: 'Update failed - File was too big!' } ]
Error flashing: err=nullDATA.OK=false
Error flashing: CODE=200
Error flashing: ERRORS=[object Object]
Error flashing: ID=undefined
Error flashing: STATUS=undefined
Error : An error occurred while flashing the device:
the selected serial port
does not exist or your board is not connected
Checked the size of BlinkTestPgm.cpp.bin and was reported as 259KB by file explorer. So why the file too big error?
exeng
-
Checked the size of BlinkTestPgm.cpp.bin and was reported as 259KB by file explorer. So why the file too big error?
The Oak reports its maximum ROM size to the Particle Cloud when it connects. I suspect this error results from the cloud getting this number wrong (probably zero) and comparing the size of the file to flash.
This is interesting. Before the fixes Erik added in 1.0.5, PeterF saw some strange behavior where his Oak would take a long time to connect, and when it finally did, the Particle Cloud would print out an unexpected event with the system description string the Oak sends on connection to the cloud (which includes the maximum ROM size). I wonder if there's still some issue here with the way the cloud is parsing this description string.
Let me try and draw Erik and the Particle folks attention to this and see if they can spot any issues. It might be a while, since they all seem to be very busy.
-
kh, Let me know if there is anything I can do to help.
exeng
-
Some additional info to add to the puzzle:
Same Oak is still failing so I decided to bring up my (straight of the package) only virgin Oak. Let's call it OAK_SPARE.
Using the 1.0.5 repro and OakCLI 1.0.2 (latest with my debug output)
1. Did a factory restore on OAK_SPARE.
2. Did SoftAp update on OAK_SPARE.
3. Did a OTA upload of a simple blink test program to OAK_SPARE.
It flashed and ran as expected. All OK... OAK_SPARE working.
Then tried the same on the failing OAK. Let's call it OAK_FAIL.
Using the 1.0.5 repro and OakCLI 1.0.2 (latest with my debug output
1. Did a factory restore on OAK_FAIL.
2. Did SoftAp update on OAK_FAIL.
3. Did a OTA upload of a simple blink test program to OAK_FAIL.
OTA upload fails with the same debug output reported on previous fails...
OakCLI tool version 1.0.2
Using config file at: C:\Users\Stephen\AppData\Roaming\oak\config.json
Sending file to cloud, to flash OAK_GD (Device ID: d9Removed for public consumption)
Get ready to flash C:\Users\Stephen\AppData\Local\Temp\build8316527855105053068.tmpBlinkTestPgm.cpp.bin
null
{ ok: false,
code: 200,
errors:
[ { id: 'd9d9Removed for public consumption',
status: 'Update failed - File was too big!' } ] }
So as reported err = null, data reports file was too big!
So why the difference? BTW, both are claimed and seen on Particle. The only thing that is different (I think) is OAK_FAIL had been previously in service (at repo 1.0.0) and posting events to Particle before all this started. At some point OAK_FAIL events were no longer seen on Particle. For that and other reasons I decided to update OAK_FAIL which now cannot be OTA uploaded.
-
If you want to give something else a try, as it's seeming even more likely it's on the Particle end, try unclaiming your Oak (go to Particle Console (https://console.particle.io/), and click the "..." next to the offending Oak and unclaim), and run it through the OakRestore / SoftAP update process again to make it claim again. Maybe that will get something unstuck.
If it doesn't want to automatically claim, you can do a manual claim as noted in the wiki (http://digistump.com/wiki/oak/tutorials/manual_claim).
Hopefully this will knock it on the head, as you seem to have eliminated just about everything on your end!
-
Pete, Been down that path already with no luck (See the earlier posts).
I have factory restored and firmware updated multiple times trying to make it go away. Then resorted to trying to get more info with the help of kh.
On the good side, we have a repeatable failing Oak. Would really like to know what Particle is seeing during the OTA exchange and how they are handling it. I can try it again (really... one more time?) but I'm feeling like there is something about this Oak that Particle doesn't like. If I were a conspiracy theorist, I'd wonder if Particle is denying my Oak from participating.
-
Pete, Just for you and only you, I did it one more time making sure to un-claim the Oak first.... and no cigar. Same result on OTA sketch upload attempt. Same error message.
-
kh, Pete, et al
BTW posted on Particle Community:
https://community.particle.io/t/error-occurred-while-flashing-device-with-digistump-oak/24060/23?u=exeng
-
Pete, Just for you and only you, I did it one more time making sure to un-claim the Oak first.... and no cigar. Same result on OTA sketch upload attempt. Same error message.
Aw... thank you! :D Ok, I'll go with the conspiracy theory... the Particle gatekeeper is obviously saying 'This Oak Shalt Not Pass' :D
For giggles, if you want, we can trade device IDs of your problem Oak (via PM) and my usual test subject, and see if we can flash each others Oaks (that just sounds wrong!)... and then swap back after trading notes. Should be as easy as an unclaim to free up, and a manual claim to attach to another Oak. No reflashing required :)
-
I was actually thinking about doing that and using an id from one of my working Oaks but didn't know if that would cause a problem or worst rendering two Oaks down.
Let me think about it.
-
Pete, tried to use one of my id's from another oak. Unclaimed both. Follow the wiki for setting the device id but it didn't change. Could be I'm doing something wrong. It would be a great experiment if I could get it to stick. In any case did yet another restore / SofAP update. Verified that the original id was there and claimed on Particle. Still no OTA upload success.
-
For giggles, if you want, we can trade device IDs of your problem Oak (via PM) and my usual test subject, and see if we can flash each others Oaks (that just sounds wrong!)... and then swap back after trading notes.
You can effectively do the same thing yourself by creating a second Particle account, then unclaiming from the original account and claiming on the second. I tried this when debugging this issue on my Oak in June. The Oak continued to behave the same way on the new account. But it would always be interesting to see whether this is repeatable or not, since this problem is so intermittent and rare.
-
kh, Thanks. Will give that a try when Pete let's go of my device-id (an experiment in progress).
-
Well, it seems exeng can upload code from his end to my test subject without any drama. However I can't claim his Oak (yes, it was unclaimed!! ;D). Think we're getting nearer to the heart of the problem though... maybe... possibly?? :o
btw, I'm trying to get a IRC channel up for any Oak related discussion... hopefully this works :)
---
Join us on IRC chat on Freenode (chat.freenode.net) in your preferred IRC client or via the web client (https://webchat.freenode.net/) at ##DigistumpOak.
-
kh, Also fails on second account. Another tidbit to log in the mystery of why. At this point, I'm torn between donating the Oak to Erik for debug and continuing to work on figuring out the problem.
I think, it will require getting Particle involved somehow to see what is going on an their end.
-
kh, Also fails on second account.
Yes, I expected it would. Good to know at least that is repeatable...one less permutation to worry about!
I think, it will require getting Particle involved somehow to see what is going on an their end.
I've sent a message to Erik asking him to take a look at the OakCore code where the Oak communicates its maximum firmware size to the cloud. I've also asked the Particle developers who were helping me to debug my instance of this issue to take a look at the Particle Cloud code that parses this communication on their side. Exeng, I sent them a link to your thread and mentioned that I'm sure you'd be happy to provide your device id so that they could look it up in their logs, so they might contact you about that.
I'll post here if I get any responses.
-
kh, Thanks. Happy to help get to the bottom of this.
-
Update but on a side issue for a complete picture...
There is something very strange going with this Oak. It seems to have difficulty with the claim process. After trying to go through the restore/SoftAP update it does not auto claim and manual claim fails (Pete, perhaps why you couldn't claim it). It seems to only claim when completed during SoftAP process.
http://192.168.1.70/particle = Connected
http://192.168.1.70/device-id = {"id":"d9Removed for public consumption","c":1} Note the "c":1 (Claimed)
And yet it is not claimed nor can it be claimed according to Particle.
Again, let's just log this and say focused on the OTA fail. Only mention it in case there is some connection to the OTA issue. I'm trying to get it back to claimed (which I have been able to do during this debug effort) so that we can debug the repeatable OTA fail.
-
OK back to claimed and active. OTA still fails with same error.
At this point I have done all I can do to help figure this out. It's time for the big boys (Erik and Particle) to get involved per kh's recommendation.
-
My head is spinning...
This will either add to solving the mystery or add confusion...
If you remember I said I brought up a brand new Oak out of the bag under the same environment and steps as I have been using for the failing Oak. I also reported that the new Oak was working fine (and it is). In my desperate search for any and all info that would help, I dumped the "info" from both Oaks and it seems that the new (working) Oak somehow loaded version 6 and system-version 1.0.0 while the failing Oak has version 10 system-version 1.0.5. I swear I've been using the same process of restore/SoftAP update for both. Same restore master.
Failing Oak "system_version":10,"version_string":"1.0.5","meta_id":0,"meta_data":"","first_update_domain":"oakota.digistump.com","first_update_url":"/firmware/firmware_v1.bin"
New Oak "system_version":6,"version_string":"1.0.0","meta_id":0,"meta_data":"","first_update_domain":"oakotafallback.digistump.com","first_update_url":"/firmware/firmware_v1.bin"
Note the update_domain "oakotafallback.digistump.com" for the new Oak. Again, I'm pretty sure I did the same restore/SoftAP update steps on both.
Since the 6 / 1.0.0 combo is working, I'll try to get this on the failing Oak to see what happens.
-
I'm happy for kh to prove me wrong, but I suspect that means the fallback server has an older copy of the firmware than the primary one. When you did the SoftAP update with the new Oak, did you have to tell it to update more than once? SoftAP is supposed to use the fallback server for retries, and that maybe how it does it (by changing the first_update_domain setting on the Oak), as it is the oak that does the actual update... SoftAP just gives it a not so gentle prod to actually go and do the update.
The easiest way to push the fallback firmware file onto your misbehaving Oak is to do the serial update, and use the firmware file from https://oakotafallback.digistump.com/firmware/firmware_v1.bin
The command line you need is at the bottom of the OakRestore page (https://github.com/digistump/OakRestore). The only difference here is to do the update, you connect P2 to GND on power on (not a typo, P2), putting the Oak into serial upload mode.
I can't tell you what version it actually for *certain* as I don't have a copy of the 1.0.0 binary any more, but I suspect it is actually v1.0.0, and hasn't been updated since the first stable release was pushed. The system_version numbering has a strange history meaning it doesn't always relate to the actual version of the firmware (hence the reliance on the version_string over the system_version to actual work out the firmware version installed :-/).
-
Pete, RE:
When you did the SoftAP update with the new Oak, did you have to tell it to update more than once?
I cannot remember how that exactly went down. But I'm sure I was going through the same process with the same files/environment when updating the new and failing Oak. So you can imagine my surprise upon seeing the different versions. And... since there seems to be no easy way to get version 6 system version 1.0.0, it must have been done (as you say) without my intervention.
I'll give your suggestion a try but if it fixes the Oak we'll lose the failing Oak. I guess, I can go through the normal restore/SoftAP to get back to it's abby normal failing state.
-
Pete, Could not download the oakatafallback image. Unlike the link to the latest oakota image link which prompts for download, the link you provided just dumps raw to the screen (also had to ignore certificate warnings). That said, I most definitely did not purposefully install version 6 system version 1.0.0 on the new Oak. But at least it works.
I'll just put the failing Oak back to it's failing state at version 10 system version 1.0.5 (actually it's still in that state) and wait on Erik and Particle assuming kh's request to them sparks interest in solving this. Not going to touch my remaining Oaks until this is sorted out.
Really need to see more detail on the exchange and the traffic between Oak and Particle.
-
lol... yeah, the certificate warning error is normal here... both the primary and fallback links will give them.... didn't realise the fallback image would't prompt for download, and instead show the contents of the file (as exciting a read as it isn't!)... I just shoved the link into my download manager so didn't browse directly to it. If you still want the image, you can grab it from my dropbox (https://www.dropbox.com/s/nxdbzgdfj06qiwv/oakotafallback_firmware_v1.bin?dl=0)... freshly downloaded from a few hours ago.
Either way, all I think happened is the when time you told the Oak to update as part of SoftAP, the Oak fell over partway in, so when SoftAP prompted you to retry, it switched the Oak over to the fallback server, and since that hasn't been updated / has the older firmware, it gave you v1.0.0.
The only other info I can give you that may help in debugging is the particle api url, which you can view to see what particle reports about your device. It looks like this:
https://api.spark.io/v1/devices/DEVICE-ID/?access_token=ACCESS-TOKEN
Where you substitute your device id and access token (you can find both on Particle Build if you need them) and shove that into the address bar of your browser. You should then get an exciting white page with the following exhilarating output.
{
"id": "DEVICE-ID",
"name": "Oak1",
"last_app": null,
"last_ip_address": "58.XY.45.XYZ",
"last_heard": "2016-08-16T07:05:04.841Z",
"product_id": 82,
"connected": true,
"platform_id": 82,
"cellular": false,
"status": "normal",
"variables": {},
"functions": []
}
Don't know if that will really gives you anything more than what OakTerm does... but more info is good, right? ;D ;D 8)
-
Pete, Thanks. I'll try these next round. So far on points I'm getting beat. Looking for the knockout punch.
Cheers.
-
Nah, you'll win one way on the other... either you'll beat it at it's own game or just introduce the Oak to 120v AC to brighten it's day :D
-
Pete, kh, et al,
OK... So this morning I just tried the Particle API as suggested. For the new Oak and the failing Oak, when each powered on they appear to be connected to Pariticle as the blue dot is on the dashboard and flashing. The API devices request looks mostly normal for both expect Pacticle reports connected true for the new Oak and connected false for the failing Oak. I assume Particle won't flash if it doesn't think an Oak is connected. Also last_heard report is consistent with what I would expect for both Oaks.
Failing Oak...
...
"last_heard": "2016-08-16T15:33:53.371Z",
"product_id": 82,
"connected": false,
"platform_id": 82,
"cellular": false,
"status": "normal",
"variables": null,
"functions": null
New (working) Oak... ...
"last_heard": "2016-08-16T15:54:21.678Z",
"product_id": 82,
"connected": true,
"platform_id": 82,
"cellular": false,
"status": "normal",
"variables": {},
"functions": []
So why ???? the flasing blue dot on Particle for the failing Oak when it's powered up and Particle doesn't think it's connected? When powered down Particle's dot stops flashing (albeit with a delay). And yes, I check the failing Oak when powered down and it's reported as connected false. Also checked the Oak "IT'S-LOCAL-IP"/particle and got back "Connected" from the system.
BTW Oak Terminal (which I believe gets this info) also shows the failing Oak "offline".
Haven't tried the fallback image yet. Time for morning coffee.
-
Latest update...
Loaded the Oak fallback image that Pete provide, which shows as system_version 6, version_string 1.0.0 as does the new working Oak. Verified by the following:
Failing Oak reports
http://192.168.1.70/version {"v":1}
http://192.168.1.70/info {"id":"d9Removed for public consumption","claimed":1,"claim_code":"","server_address_type":1,"server_address_domain":"device.spark.io","system_version":6,"version_string":"1.0.0","meta_id":0,"meta_data":"","first_update_domain":"oakota.digistump.com","first_update_url":"/firmware/firmware_v1.bin","first_update_fingerprint":"98 66 d5 5c 3d 4a 49 24 e3 1b 72 8b 8f 2e 65 2e 32 2a 7b 95"}
http://192.168.1.70/particle Connected
Cannot claim the device nor OTA upload. It was previously claimed and present (even after the load of the fallback image) but couldn't OTA upload. Unclaimed it, cycled power, can't claim it (which has been an ongoing behavior. Claims only when SoftAP update works.
Makes you wonder what is real difference between to new working Oak and the failing Oak under test/debug.
This whole claim thing is looking suspect with Particle... and I also don't understand when I do have it claimed and present on Particle why Particle API reports it's connect status as false. Wondering if something is out of sync with Particle's view of this device.
I'm going to go through the normal factory restore / SoftAP update once again to get it back to it's (other) failing config. The one I have been trying to resolve for days. I've poked it from every which way to no avail. Double Arrrrgh!
-
I got a response from the Particle developers yesterday to say they think your debugging info may help to narrow down the issue, exeng. I suggested they get in touch with you to get your device ID to compare with their logs, or perhaps a full image of your Oak (that way, if you unclaimed yours, they could effectively make a clone for in-house testing - I'll write up some instructions on making a full image if they're interested in doing this).
-
Thanks. Also sent an appeal to Erik as did you. Offered the device id and/or the physical Oak. At this point I've done all I can do.
Would like to know from Particle why their flashing online indicator on the device screens does not match what is returned from Cloud API connect status for this Oak. Posted a ? on Particle Community but so far only readers and no answers. https://community.particle.io/t/dashboard-build-device-status-question/25179
Thanks for all the help. If nothing else, I learned a lot during this exercise. But I still want to nail this.
(oh... and Thanks to Pete also).
exeng
-
Yet another update...
Checking Particle Cloud API again after OTA failing Oak powered up and...
"connected": true,
So naturally I was excited to try an OTA sketch upload. Result fail. Same error as before with my additional debug output showing err (null) and data objects.
OakCLI tool version 1.0.2
Using config file at: C:\Users\Stephen\AppData\Roaming\oak\config.json
Sending file to cloud, to flash OAK_GD (Device ID: d9Removed for public consumption)
Get ready to flash C:\Users\Stephen\AppData\Local\Temp\build2369503282518711042.tmpBlinkTestPgm.cpp.bin
null
{ ok: false,
code: 200,
errors:
[ { id: 'd9Removed for public consumption',
status: 'Update failed - File was too big!' } ] }
Error : An error occurred while flashing the device:
-
I have same the problems since a few days.
So i did a restore over serial (took the latest firmware_v1.bin form 09-Jul-2016 13:40).
Now i see the device is up on particle.
When i try to flash the simple blink example it starts to flash (oak blinks).
After a few seconds i see the OAK stops blinking, but the IDE still shows Flashing.
Oak is going back to "fresh install" blinking and shows on particle "No user rom found".
Then the IDE tells me "Error : Oak is back online before flash sucessfull."
The Oak clearly gets restarting within the flashing process. I can not get any new FW on it.
OakCli: 1.0.2
OakArduino package: 1.0.5
-
saperlot, I think what you are seeing is different than the problem I'm having. I've seen the error you posted few times over the course of using my Oak's (many months)...
"Error : Oak is back online before flash sucessfull."
and it's always been a transient problem. Never understood why but usually resolved itself upon a retry. Can't say that I've seen the other part you mention......shows on particle "No user rom found".
since it would go away on retry.
Is it repeatable? Have you tried all the usual stuff... Safe mode before trying to upload a sketch, or doing a factory restore and normal OTA firmware update rather than serial update?
The problem I have been chasing is that I have an Oak the refuses to OTA upload a sketch. I've got the latest system SW on it and using 1.0.5 and CLI 1.0.2. I'll spare the details as they are well documented in this thread. The big guns may be getting involved in trying understand what is going on. Hopefully we'll get to the bottom of this.
-
With respect the OTA upload failing Oak that I have been trying to debug (as described in this ongoing thread), add the following information to the list of behaviors:
This Oak DOES NOT report the online spark/status and oak/devices/stderr via the Particle Cloud API as seen in the example below which is from a working Oak when powered up.
event: spark/status
data: {"data":"online","ttl":"60","published_at":"2016-08-17T23:39:49.700Z","coreid":"d9Removed for public consumption"}
event: oak/devices/stderr
data: {"data":"Config Mode","ttl":"60","published_at":"2016-08-17T23:39:50.646Z","coreid":"d9Removed for public consumption"}