Digistump Forums
The Oak by Digistump => Oak Support => Topic started by: lopemac on June 15, 2016, 04:25:01 am
-
I installed the 1.0.2 firmware onto my oak using Arduino 1.6.5 for Mac and the wifi connection became erratic on my oak and a rotary encoder sketch that was working before became very unusable. I installed ver 1.0.1 and the problems went away. The oak started working properly. I tried 1.0.2 again, but I had the same bad results. Have other users had this problem?
-
Dear friend,
sorry to say that this is my experience to my 4 Oak's when updated to 1.0.2 firmware with much different "host" configuration than yours: Windows 7 64, Arduino 1.6.{7,8,9} !
Something ware bad there inside the last update of 1.0.2 ...
At the moment I stopped all and I been waiting for a new release. I was so badly disappointed that I did not even report it...
So I know what do you feel...
Best Regards,
Mike Kranidis
-
Well, now I know it's not just me. I'm glad it's possible to revert to old firmwares. I had skipped over 1.0.1 to try 1.0.2 and I'm glad 1.0.1 is working for me. Hopefully the next update will be better.
-
I haven't had quite as bad an experience as you guys when I updated one of my Oaks to 1.0.2, but something certainly with amok... it become a lot less responsive to OTA updates, and needed to be put into safe mode to reliably update. I knew there was some sort of issue though, due to a few other comments, so my main units are still with 1.0.1. I really do like the OakTerm functionality that was introduced with 1.0.2, and hopefully that isn't the root of the issue!
-
Question: How are you getting these specific firmware revisions? I have 5 oaks that I'm trying to get working again (I had them all working on pre-1.0 but they've been set aside for a while).
I tried going through the serial firmware loads but apparently now it forces a 1.02 download? which when that fails directs me to a page to put the firmware I just loaded back on and am anxious to avoid that process x5.
-
The firmware versions can be installed using the Arduino application by going into the board manager section and selecting the firmware version for Oak by Digistump. The versions automatically show up and you just select the one you want to install. When you upload code the version you select installs on the oak. If you go the serial route then you lose the ability to use wifi uploading of code. I had a very hard time getting the first update onto an oak and serial worked but it's not ideal. I tried updating another oak to the first released firmware and it took a couple of tries but it finally worked. Definitely not easy doing the first updates on these oaks.
-
tcarleton is probably referring to the serial update process (not to be confused with serial upload!!), whereby you grab the latest firmware from the digistump server, which then forces you to use 1.0.2. You don't loose the ability to do OTA updates, it's just more awkward unless you are updating several units and have wifi or internet issues. When you do an OTA upload via the Arduino IDE, the version of the boards package (which you can choose) will determine what version of the OAK firmware will end up on your Oak, as it compiles it every time. The only thing that isn't affected is the safe mode firmware, which remains at the version that was live when you commissioned the Oak, or when you last did an OakRestore. Erik is looking at making it so the Particle update process can also update the safe mode firmware automatically.
-
Has anyone reported these problems to Erik? I haven't seen him around the forums, but if there are problems with latest firmware, he ought to know....
-
Well I regret not seeing this sooner - I have been away from most things Digistump besides keeping orders shipping and emails answered, as time has been very limited with helping to care for our 2 year old and newborn - now 2 months old - who has had a bit of a rough start - but is healthy none the less.
I just pushed 1.0.3 with some fixes by @kh, I think these might address the issues people were seeing here, but if anyone can test (because 1.0.2 has worked fine for me) I'd very much appreciate the feedback, and I will check back here to see it
Thanks!
-
When I try to download 1.0.3 via arduino IDE (1.6.5r2 or 1.6.9) I get: Invalid archive: it must contain a single root folder
-
When I try to download 1.0.3 via arduino IDE (1.6.5r2 or 1.6.9) I get: Invalid archive: it must contain a single root folder
same happened to me!
Any workaround or solution?
-
Should work now - sorry about that!
-
Here's what I find with 1.0.3, using the Start example. This blinks an LED, with a two second rep rate.
When I first program the Oak, the sketch runs fine; that is, it has a 2 second rep rate.
When I power off and on, it takes many seconds (32 or so) to boot, then blinks the LED, but there is a 6 second rep rate. I put yield() statements before the two delays, but that has no effect.
void loop() {
digitalWrite(1, HIGH); // turn the LED on (HIGH is the voltage level)
yield();
delay(1000); // wait for a second
digitalWrite(1, LOW); // turn the LED off by making the voltage LOW
yield();
delay(1000); // wait for a second
}
I also note when reflashing it takes a long time. Rebooting times out (the dots stop being printed).
I can cycle the power, and it boots successfully and works (slowly).
Cutting the delays down to 500 each makes no difference at first, but after a few minutes it runs at speed.
The board manager says I have 1.03, but when the compiler starts, it prints: OakCLI tool version 1.0.2
-
Should work now - sorry about that!
Um Erik... did you break it again? :P :P :o
I was about to update, and can't update to 1.0.2 and 1.0.3, but now realise this is deliberate - you've reverted to 1.0.1 being the latest whilst debugging 1.0.2 & 1.0.3.
For anyone wondering how I know... it's not that I have a secret direct line to Erik ( ;D ) - it's what Erik said the revert was for on the github repo for the board manager json file (https://github.com/digistump/arduino-boards-index/commits/master)! ;)
-
Thanks, PeterF
I will check the GitHub myself in the future. Yesterdays good code doesn't run today - I was not having issues w 1.0.3 (or 1.0.2 for that matter). If it is any value -- since I was running OK -- I had done a serial (non-OTA) restore after a previous disaster-- perhaps I got some slightly different firmware state after serial Flash and first OTA from that.
Hopefully we will have a working (1.0.4?) version soon.
James
-
Yes I've rolled back 1.0.2 and 1.0.3 because I want to get to the bottom of these issues reported before leaving those out in the wild - my testing shows 1.0.3 working well, but there are too many reports here to not dig deeper and try to reproduce - I've asked @kh to look into this as well, as all the commits since 1.0.1 were (very kindly!) submitted by him, and could or could not be related to this.
We'll get it fixed and into 1.0.3 as soon as possible, and I'll update here when we do.
-
@aztorell - would you mind testing the same way with 1.0.1 to confirm that things work well with that for you?
-
I've battled with the toolset for an hour now. Got all the boards uninstalled, and installed 1.0.1. But I don't have success flashing the part. I've even grounded pin 1 before loading. Several times it would start to flash (dots incrementing), and then fail. Now it never acknowledges flashing. The particle dashboard indicates it's communicating when I start flashing by the timestamp.
Sending file to cloud, to flash xxxxxxx
Error : An error occurred while flashing the device:
-
Does it continue failing to acknowledge/respond to flashing when in safe mode (P1 to GND)... Also, once you've entered safe/config mode, do you pull the jumper so you can see the P1 doing it's triple flash thing? (The jumper only needs to be connected at boot, you can remove it after 1-2 seconds). If your Oak still has the 1.0.1 config/safe mode core on it, you should see the P1 led start blinking erratically if it is accepting an OTA update.
-
When I try the safe mode, I pull the jumper after it boots, and I see the triple flash, as normal. I could also power cycle without the jumper, and it triple flashes, even if it has partially flashed.
After Many tries, it accepted programming, and rebooted. It cycled with the 6 second period like with the 1.0.3 load. After about 5 minutes, it settled into a 2 second (expected) rep rate. I cycled the power, and it went back to a 6 second rep rate, for about 20 minutes, then settled into a 2 second rate.
So, it looks like 1.0.1 behaves the same as 1.0.3. Although, it was much easier to reprogram with 1.0.3.
Another odd thing I have seen occurs when my wi-fi goes down (I shut off the modem when the kids are getting ready for school). The oak goes back into a triple flash operation within a few minutes of wi-fi loss.
-
On that last point
Another odd thing I have seen occurs when my wi-fi goes down (I shut off the modem when the kids are getting ready for school). The oak goes back into a triple flash operation within a few minutes of wi-fi loss.
this is expected behaviour. When you have the Oak in the 'Pin 1 Safe Mode - Default', if you Oak doesn't see it's registered access point for some set time period (I seem to remember 3 minutes being mentioned?), it auto falls back to safe/config mode waiting for you to reconfigure the access point settings. If you don't want it to do this, change to the 'Pin 1 Safe Mode - Manual Config Only'. In this mode, if it doesn't see the wireless, then too bad, it keeps trying. It then only goes into safe/config mode if a code upload goes wrong, or you manually trigger it.
-
@lopemac, @mikekgr did you have a chance to try firmware 1.0.3 while it was available for download? I had hoped it would help with the issues you were encountering with 1.0.2. If it doesn't help, there must be another underlying problem that we haven't found yet.
-
@lopemac, @mikekgr did you have a chance to try firmware 1.0.3 while it was available for download? I had hoped it would help with the issues you were encountering with 1.0.2. If it doesn't help, there must be another underlying problem that we haven't found yet.
Dear Kh,
yes I tried 1.0.3 before Eric take it out and I found capable doing OTA flash as it should! I did not extensively tested because the next day it was out from Arduino...
Best Regards,
Mike Kranidis
-
Thanks for the update @mikekgr
If you want to install 1.0.3 (actually 1.0.4 beta now) before it is officially finished and released, then use the following steps:
- Download 1.0.4 beta from my fork of OakCore on GitHub here: https://github.com/kh90909/OakCore/archive/restore-ota-blink.zip
- Delete everything in the folder APP_DATA\Arduino15\packages\digistump\hardware\oak\, where APP_DATA is where your system keeps the Arduino data (usually C:\Users\<username>\AppData\Roaming on Win 7/8/10). This clears out all references to the pulled 1.0.2 board version that can cause problems.
- Use the Arduino IDE Boards Manager (Tools menu -> Board -> Boards Manager...) to install Oak by Digistump version 1.0.1
- Delete everything in the APP_DATA\Arduino15\packages\digistump\hardware\oak\1.0.1\ directory
- Copy the contents of the OakCore-restore-ota-blink directory inside the zip into APP_DATA\Arduino15\packages\digistump\hardware\oak\1.0.1\
- Rebuild your sketch in the Arduino IDE. Boards Manager will still say version 1.0.1, but it will use the copied 1.0.4 beta files.
To go back to 1.0.1, use the Arudino IDE Boards Manager (Tools menu -> Board -> Boards Manager...) to remove the installed version, then reinstall it (or whatever version you want).
-
Dear kh,
I will try today at night Greek Local Time and I will report back to you.
Best Regards,
Mike Kranidis
Thanks for the update @mikekgr
If you want to install 1.0.3 (actually 1.0.4 beta now) before it is officially finished and released, then use the following steps:
- Download 1.0.4 beta from my fork of OakCore on GitHub here: https://github.com/kh90909/OakCore/archive/restore-ota-blink.zip
- Copy the contents of the OakCore-restore-ota-blink directory inside the zip over the files found at APP_DATA\Arduino15\packages\digistump\hardware\oak\XXX, where APP_DATA is where your system keeps the Arduino data (usually C:\Users\<username>\AppData\Roaming on Win 7/8/10) and XXX is the Oak version you have installed in the Arudino IDE Boards Manager (Tools menu -> Board -> Boards Manager...) Most likely, you have version 1.0.1.
- Rebuild your sketch in the Arduino IDE. Boards Manager will still say version 1.0.1, but it will use the copied 1.0.4 beta files.
To go back to 1.0.1, use the Arudino IDE Boards Manager (Tools menu -> Board -> Boards Manager...) to remove the installed version, then reinstall it (or whatever version you want).
-
Please bring back 1.02. So far i had no issues.
Some minutes ago i just wanted to bring another Oak to life with my app, but as i see now, Eric just dropped 1.02 and probably every user out there who had 1.02 installed is now unable to flash.
It is also not possible to just load 1.01 thru the Arduino Menu.
Very disappointing, this move.... make me a bit angry, to be honest.
-
Thanks for the update @mikekgr
If you want to install 1.0.3 (actually 1.0.4 beta now) before it is officially finished and released, then use the following steps:
- Download 1.0.4 beta from my fork of OakCore on GitHub here: https://github.com/kh90909/OakCore/archive/restore-ota-blink.zip
- Copy the contents of the OakCore-restore-ota-blink directory inside the zip over the files found at APP_DATA\Arduino15\packages\digistump\hardware\oak\XXX, where APP_DATA is where your system keeps the Arduino data (usually C:\Users\<username>\AppData\Roaming on Win 7/8/10) and XXX is the Oak version you have installed in the Arudino IDE Boards Manager (Tools menu -> Board -> Boards Manager...) Most likely, you have version 1.0.1.
- Rebuild your sketch in the Arduino IDE. Boards Manager will still say version 1.0.1, but it will use the copied 1.0.4 beta files.
To go back to 1.0.1, use the Arudino IDE Boards Manager (Tools menu -> Board -> Boards Manager...) to remove the installed version, then reinstall it (or whatever version you want).
Wanted to try your beta, but seems to be a change in description of oak boards in .json config or boards txt files. I keep getting this error:
Board oak1 (platform oak, package digistump) is unknown
Error compiling for board Oak by Digistump (Pin 1 Safe Mode - Default).
when I try and compile a sketch that worked on 1.0.3 before pull.
Can you tell me which file/where to modify the "name" of the Oak so I can get it to compile fooling IDE into thinking I have 1.0.1 with your 1.0.4 replacing it. Or was there a file I should have deleted from 1.0.1 directory before I copied your files it? I just copied and said to replace all files.
Thanks James
-
Can you tell me which file/where to modify the "name" of the Oak so I can get it to compile fooling IDE into thinking I have 1.0.1 with your 1.0.4 replacing it. Or was there a file I should have deleted from 1.0.1 directory before I copied your files it? I just copied and said to replace all files.
Sorry for the ambiguity. I thought that copy and replace all would do the trick, but I actually deleted everything in the 1.0.1 directory before replacing with the contents of the zip (well, I git cloned the repo there, but it achieves the same thing).
Try deleting the contents of 1.0.1 before copying there. If this doesn't work, let me know and I'll investigate further.
-
...probably every user out there who had 1.02 installed is now unable to flash.
It is also not possible to just load 1.01 thru the Arduino Menu.
Hi @saperlot, I understand your frustration. Are you saying that when you go back to 1.0.1 via the Arduino IDE boards manager, it gives an error when you try to flash? Or something else?
In the Arduino IDE, you should be able to load 1.0.1 (or 1.0.0) by going to the Tools menu->Board: ...->Boards Manager... and then scrolling to the bottom (see the screenshot attached). If you don't see any Digistump options, make sure you have the Boards Manager URL set under File menu->Preferences. See here (http://digistump.com/wiki/oak/tutorials/arduino) for instructions. Let us know if this doesn't work and we'll do our best to help you out.
If you wish, you should also be able to try 1.0.4 beta by following the instructions in my post (https://digistump.com/board/index.php/topic,2310.msg10841.html#msg10841) above.
-
Saperlot won't have rolled back to 1.01. There is a big issue in the Arduino IDE boards manager in that when you remove a board version from the json file, if you had previously had that version installed, it stops working. Hence, for anyone who updated to 1.0.2, when the ide next auto-updates all the boards files, it suddenly goes, 'hey, there's no board package here' (the "Board oak1 (platform oak, package digistump) is unknown" message)... and basically you are up the creek unless you know what is going on.
When that happens, you go into the board manager, remove that offending board/version, and then you install whatever version you can (1.0.1 in this instance... unless you do the beta test 1.0.4).
-
Saperlot won't have rolled back to 1.01. There is a big issue in the Arduino IDE boards manager in that when you remove a board version from the json file, if you had previously had that version installed, it stops working. Hence, for anyone who updated to 1.0.2, when the ide next auto-updates all the boards files, it suddenly goes, 'hey, there's no board package here' (the "Board oak1 (platform oak, package digistump) is unknown" message)... and basically you are up the creek unless you know what is going on.
When that happens, you go into the board manager, remove that offending board/version, and then you install whatever version you can (1.0.1 in this instance... unless you do the beta test 1.0.4).
Even then, Arduino still says:
Board oak1 (platform oak, package digistump) is unknown
Error compiling for board Oak by Digistump (Pin 1 Safe Mode - Default).Happened to me in OSX yesterday and today on a win machine.
trying to remove 1.01 gives:
Could not find boards.txt in C:\Users\[username]\AppData\Local\Arduino15\packages\digistump\hardware\oak\1.0.1. Is it pre-1.5?
this Folder exists but doesn't have files in there. Arduino still thinks that this board is installed.
Removing the folder 1.01 gives me the option to install it again in Arduino. Doing this will result still in the same "Board oak1 is unknown". Only removing the folder 1.0.2 C:\Users\[username]\AppData\Local\Arduino15\packages\digistump\hardware\oak\ gives me again the option to build it successfully.
i use Arduino 1.6.9.
So please, never ever delete items in your package Json.
-
Thanks for the explanation.
So it sounds like my instructions for 1.0.4 beta should also say (between steps 1 and 2):
- First remove all existing "Oak by Digistump" boards with Boards Manager
- If this gives an error, delete the corresponding folder from "AppData\Local\Arduino15\packages\digistump\hardware\oak\"
- Reinstall the latest version available with Boards Manager
Can you confirm this is correct?
@PeterF, for people that have not made any changes in Boards Manager, do you know if things will start working again, without any intervention on their part, if @digistump restores 1.0.2 on his server?
-
Thanks for the explanation.
So it sounds like my instructions for 1.0.4 beta should also say (between steps 1 and 2):
- First remove all existing "Oak by Digistump" boards with Boards Manager
- If this gives an error, delete the corresponding folder from "AppData\Local\Arduino15\packages\digistump\hardware\oak\"
- Reinstall the latest version available with Boards Manager
I can't reproduce it, but should work..
Can you confirm this is correct?
@PeterF, for people that have not made any changes in Boards Manager, do you know if things will start working again, without any intervention on their part, if @digistump restores 1.0.2 on his server?
-
I'm not sure... I don't see why not so I think is just a version check, but the Arduino folks have some strange ideas at times! :-O I expect that the 1.0.2 board could be restored in the json, and when they either manually refresh by opening the board manager and letting it check for updates, or just leave the IDE open for a few minutes so it does it itself in the background, all should be good again... And yes, your updated instructions should be good... the oak folder should just be emptied of its contents...
-
Thanks for the feedback @saperlot and @PeterF. I've updated my 1.0.4 beta install instructions post (https://digistump.com/board/index.php/topic,2310.msg10841.html#msg10841).
-
I apologize both for the delay on my part and the issues caused by pulling 1.0.2 - even after years of working with the Arduino IDE I still don't always understand everything it does or that will cause problems.
I've restored 1.0.2 in the JSON so people can upgrade from it, and added 1.0.3r2 which is the same as kh's beta 1.0.4 (many thanks to him for doing all the hard work the last two releases)
If anyone can test 1.0.3r2 and see if it makes their oak's happy, I'd greatly appreciate it
-
actually it is released as 1.0.4 instead of 1.0.3r2 as Arduino IDE doesn't accept any other type of version number
-
I'll be testing it out shortly ;)
The Arduino IDE has some interesting quirks of late, the board manager and library manager being sometimes more of a headache and hindrance than a benefit. Once you work out WTH it's doing though, everything is usually ok. Another more recent 'improvement' that I'm still not happy with is the library matching rules they use, but I can understanding the reasoning behind why they work how they do... but that has made it so I have a very peculiar setup with separate sketchbook directories and icons to load those sketchbooks, so I can ensure that Oak only sees oak stuff, STM32 only sees STM32 stuff and Arduino only sees Arduino... annoying, but surprisingly effective once you separate everything!
EDIT: I can break an oak on command! ;D :o
I have 1.0.4 on my laptop, and still have 1.0.1 on my desktop. I load some code onto my oak via the desktop-1.0.1, and works great. Load it on via the laptop-1.0.4, and it goes into the dreaded offline/online loop! Cool! 8) Put it into safe mode, and program it again with desktop-1.0.1, and no problem!
-
Hi PeterF. That's not good! We'd better try and get to the bottom of this. Needless to say, I didn't run into this issue in my testing.
Is it code specific - will the blink sketch trigger it?
Do you have any experience with "git bisect"? If so, it would be great if you could use it to find the offending commit between 1.0.1 and 1.0.4.
-
I haven't played with git too much, so no, not familiar with bisect, but I am happy to give it a try, time permitting.
It could be code specific, the code I used to test was a MQTT client, so has some rather specific code / library imports. However, it was the exact same sketch in both cases, so it still points to some change. I'll try the blink sketch in the morning to rule that out. I should point out that the Oak in question was oakrestored to 1.0.1, and hasn't been updated since - so it is only getting updates via the particle cloud, although that shouldn't make any difference? I'll pull my other sacrifacial oak out tomorrow also and rinse 'n repeat for consistencies sake...
-
Thanks PeterF.
There's a tutorial on "git bisect" here (https://git-scm.com/book/en/v2/Git-Tools-Debugging-with-Git#Binary-Search). Basically, it will do a binary search / divide-and-conquer through each code commit between the known good and bad versions, asking you to test each one.
I'm traveling at the moment, but here are some quick instructions that will hopefully get you started. I'm typing these from memory, so apologies if I get anything wrong. You might need to do some experimenting and googling to fill in the blanks:
- Install 1.0.4 with Boards Manager
- Remove the "Arduino15\packages\digistump\hardware\oak\1.0.4" directory
- Open a command prompt and change to the "Arduino15\packages\digistump\hardware\oak" directory
- In the command prompt, run "git clone https://github.com/digistump/OakCore.git 1.0.4" (this downloads OakCore into a directory named 1.0.4)
- Run "git bisect start" (Start a bisect)
- Run "git bisect bad" (Tell bisect that the current (latest) version is bad)
- Run "git bisect good 1.0.1" (Tell bisect that 1.0.1 was the last known good version. This automatically updates the current state of the OakCore git repo to half way between the good and bad versions.)
- Compile, upload and test a sketch
- Tell bisect whether it was good or bad with "git bisect good" or "git bisect bad". This then updates the current state of the repo to half way between the new good and bad versions.
- Repeat steps 8-9 above until bisect tells you it has found the first bad commit.
I think it's at least a possibility that this is MQTT specific. The code additions in 1.0.2 add more Particle subscriptions for the OakTerm communications events, and perhaps these, combined with the additional MQTT traffic are enough to clog up the tcp stack so that the Particle Cloud comms reset. The good news is that if your sketch will reliably trigger this issue for everyone, it should be pretty easy to diagnose and fix.
-
Wow... thanks for that! Thought I'd have to resort to google searches just to get some idea the WTH I'm supposed to do! ;D
Hm... was about to report that my test subject didn't like a 1.0.4 compile of a blink sketch (just the plain 'ol arduino blink, but pin 1 instead of 13), but as I was writing this it changed it's mind. Thankfully I had Oakterm still open, and caught an interesting message. I'll paste the log below. btw, the only reason I'm programming from safe mode is for consistency... because of the offline/offline cycles 1.0.4 doesn't like to program in 'normal mode' for me... but 1.0.1 is fine.
# I had the Oak in config mode, but started OakTerm after starting the Oak. Programming a 1.0.1 blink sketch
[18:08:45] Event: spark/flash/status - started
[18:09:05] Event: spark/status - offline
[18:09:05] Event: spark/flash/status - failed
[18:09:11] Event: spark/status - online
[18:10:27] Event: spark/status - offline
#Oak is happily blinking (user programmed, not triple). I may have switched the power on and off getting the second online message, just to check it was behaving.
# Loading on a 1.0.4 version of the blink sketch. As you can see it didn't go well after programming.
[18:10:41] Config Mode
[18:10:43] Event: spark/flash/status - started
[18:11:06] Event: spark/status - offline
[18:11:06] Event: spark/flash/status - failed
[18:11:12] Event: spark/status - online
[18:11:22] Event: spark/status - offline
[18:11:23] Event: spark/status - online
[18:11:33] Event: spark/status - offline
[18:11:35] Event: spark/status - online
# That's enough of this... power cycle
[18:11:42] Event: spark/status - online
[18:11:52] Event: spark/status - offline
[18:11:54] Event: spark/status - online
[18:12:04] Event: spark/status - offline
[18:12:06] Event: spark/status - online
[18:12:15] Event: spark/status - offline
[18:12:17] Event: spark/status - online
[18:12:26] Event: spark/status - offline
[18:12:27] Event: spark/status - online
[18:12:29] Event: spark/status/safe-mode - {"f":[],"v":{},"p":82,"m":[{"s":1040368,"l":"m","vc":30,"vv":30,"f":"s","n":"1","v":6,"d":[]},{"s":1040368,"l":"m","vc":30,"vv":30,"u":"0","f":"u","n":"1","v":1,"d":[{"f":"s","n":"1","v":9,"_":""}]}]}
[18:12:28] Event: spark/status/safe-mode - {"f":[],"v":{},"p":82,"m":[{"s":1040368,"l":"m","vc":30,"vv":30,"f":"s","n":"1","v":6,"d":[]},{"s":1040368,"l":"m","vc":30,"vv":30,"u":"0","f":"u","n":"1","v":1,"d":[{"f":"s","n":"1","v":9,"_":""}]}]}
#hm... just noticed it was blinking (user programmed, not triple) as I was writing the forum reply... WTH? Lets see what another power cycle does
[18:13:41] Event: spark/status - online
[18:13:51] Event: spark/status - offline
[18:13:52] Event: spark/status - online
[18:14:02] Event: spark/status - offline
[18:14:03] Event: spark/status - online
[18:14:18] Event: spark/status/safe-mode - {"f":[],"v":{},"p":82,"m":[{"s":1040368,"l":"m","vc":30,"vv":30,"f":"s","n":"1","v":6,"d":[]},{"s":1040368,"l":"m","vc":30,"vv":30,"u":"0","f":"u","n":"1","v":1,"d":[{"f":"s","n":"1","v":9,"_":""}]}]}
[18:14:04] Event: spark/status/safe-mode - {"f":[],"v":{},"p":82,"m":[{"s":1040368,"l":"m","vc":30,"vv":30,"f":"s","n":"1","v":6,"d":[]},{"s":1040368,"l":"m","vc":30,"vv":30,"u":"0","f":"u","n":"1","v":1,"d":[{"f":"s","n":"1","v":9,"_":""}]}]}
#this is just nuts... is this indicating the error is on particles end? Regardless, the oak is happily blinking again (user programmed, not triple)
EDIT1: I just programmed the MQTT sketch (https://gist.github.com/pfeerick/66ae60399e8074e04d02b9f5d9f9dd40) again with 1.0.4, and left it for longer, and it still kept endlessly offline and online-ing for a good four minutes, and then kicked out a spark/status/safe-mode and then started running the sketch.
[18:23:15] Event: spark/flash/status - started
[18:23:35] Event: spark/status - offline
[18:23:35] Event: spark/flash/status - failed
[18:23:41] Event: spark/status - online
[18:23:51] Event: spark/status - offline
[18:23:52] Event: spark/status - online
[18:24:02] Event: spark/status - offline
[18:24:04] Event: spark/status - online
[18:24:15] Event: spark/status - offline
[18:24:17] Event: spark/status - online
[18:24:27] Event: spark/status - offline
[18:24:28] Event: spark/status - online
[18:24:38] Event: spark/status - offline
[18:24:39] Event: spark/status - online
[18:24:49] Event: spark/status - offline
[18:24:50] Event: spark/status - online
[18:25:00] Event: spark/status - offline
[18:25:02] Event: spark/status - online
[18:25:12] Event: spark/status - offline
[18:25:14] Event: spark/status - online
[18:25:22] Event: spark/status - offline
[18:25:24] Event: spark/status - online
[18:25:34] Event: spark/status - offline
[18:25:35] Event: spark/status - online
[18:25:45] Event: spark/status - offline
[18:25:46] Event: spark/status - online
[18:25:54] Event: spark/status - offline
[18:25:56] Event: spark/status - online
[18:26:05] Event: spark/status - offline
[18:26:07] Event: spark/status - online
[18:26:16] Event: spark/status - offline
[18:26:18] Event: spark/status - online
[18:26:28] Event: spark/status - offline
[18:26:29] Event: spark/status - online
[18:26:38] Event: spark/status - offline
[18:26:41] Event: spark/status - online
[18:26:51] Event: spark/status - offline
[18:26:52] Event: spark/status - online
[18:27:02] Event: spark/status - offline
[18:27:03] Event: spark/status - online
[18:27:12] Event: spark/status - offline
[18:27:14] Event: spark/status - online
[18:27:26] Event: spark/status - offline
[18:27:27] Event: spark/status - online
[18:27:32] Event: spark/status/safe-mode - {"f":[],"v":{},"p":82,"m":[{"s":1040368,"l":"m","vc":30,"vv":30,"f":"s","n":"1","v":6,"d":[]},{"s":1040368,"l":"m","vc":30,"vv":30,"u":"0","f":"u","n":"1","v":1,"d":[{"f":"s","n":"1","v":9,"_":""}]}]}
[18:27:29] Event: spark/status/safe-mode - {"f":[],"v":{},"p":82,"m":[{"s":1040368,"l":"m","vc":30,"vv":30,"f":"s","n":"1","v":6,"d":[]},{"s":1040368,"l":"m","vc":30,"vv":30,"u":"0","f":"u","n":"1","v":1,"d":[{"f":"s","n":"1","v":9,"_":""}]}]}
EDIT2: And just to show it isn't just a temperamental Oak, I have subjected another one to the same abuse and it didn't like it either! I noticed this time (since I was staring at it waiting for it to behave that it would periodically do the programmed blink, but the timing was way off. i.e. one second on, 10 seconds off). I assume (I know, not a good idea!) that the other one was doing the same but I just didn't see it. It got fed up with this one after nearly 10 minutes of cycling, power cycled it and no change after two minutes - still cycling.
#lets try the blink on a different oak, with 1.0.1
[18:33:24] Device change: Oak4
[18:33:19] Event: spark/flash/status - started
[18:33:47] Event: spark/status - offline
[18:33:47] Event: spark/flash/status - failed
[18:33:58] Event: spark/status - online
[18:34:54] Event: spark/status - online
#user programmed blink, now lets try 1.0.4...
[18:35:06] Config Mode
[18:36:40] Event: spark/flash/status - started
[18:37:02] Event: spark/status - offline
[18:37:02] Event: spark/flash/status - failed
[18:37:08] Event: spark/status - online
[18:37:17] Event: spark/status - offline
[18:37:22] Event: spark/status - online
[18:37:32] Event: spark/status - offline
[18:37:33] Event: spark/status - online
[18:37:42] Event: spark/status - offline
[18:37:44] Event: spark/status - online
[18:37:53] Event: spark/status - offline
[18:37:55] Event: spark/status - online
[18:38:03] Event: spark/status - offline
[18:38:05] Event: spark/status - online
[18:38:14] Event: spark/status - offline
[18:38:18] Event: spark/status - online
[18:38:27] Event: spark/status - offline
[18:38:31] Event: spark/status - online
[18:38:40] Event: spark/status - offline
[18:38:44] Event: spark/status - online
[18:38:53] Event: spark/status - offline
[18:38:57] Event: spark/status - online
[18:39:06] Event: spark/status - offline
[18:39:10] Event: spark/status - online
[18:39:19] Event: spark/status - offline
[18:39:22] Event: spark/status - online
[18:39:32] Event: spark/status - offline
[18:39:35] Event: spark/status - online
[18:39:45] Event: spark/status - offline
[18:39:49] Event: spark/status - online
[18:39:59] Event: spark/status - offline
[18:40:03] Event: spark/status - online
[18:40:13] Event: spark/status - offline
[18:40:16] Event: spark/status - online
[18:40:26] Event: spark/status - offline
[18:40:29] Event: spark/status - online
[18:40:39] Event: spark/status - offline
[18:40:42] Event: spark/status - online
[18:40:52] Event: spark/status - offline
[18:40:55] Event: spark/status - online
[18:41:05] Event: spark/status - offline
[18:41:08] Event: spark/status - online
[18:41:18] Event: spark/status - offline
[18:41:21] Event: spark/status - online
[18:41:32] Event: spark/status - offline
[18:41:35] Event: spark/status - online
[18:41:45] Event: spark/status - offline
[18:41:48] Event: spark/status - online
[18:41:57] Event: spark/status - offline
[18:42:00] Event: spark/status - online
[18:42:11] Event: spark/status - offline
[18:42:14] Event: spark/status - online
[18:42:24] Event: spark/status - offline
[18:42:27] Event: spark/status - online
[18:42:37] Event: spark/status - offline
[18:42:40] Event: spark/status - online
[18:42:49] Event: spark/status - offline
[18:42:52] Event: spark/status - online
[18:43:01] Event: spark/status - offline
[18:43:04] Event: spark/status - online
[18:43:14] Event: spark/status - offline
[18:43:17] Event: spark/status - online
[18:43:27] Event: spark/status - offline
[18:43:30] Event: spark/status - online
[18:43:39] Event: spark/status - offline
[18:43:43] Event: spark/status - online
#that's enough of this... what about a power cycle?
[18:43:54] Event: spark/status - online
[18:44:04] Event: spark/status - offline
[18:44:06] Event: spark/status - online
[18:44:16] Event: spark/status - offline
[18:44:18] Event: spark/status - online
[18:44:30] Event: spark/status - online
[18:44:38] Event: spark/status - offline
[18:44:40] Event: spark/status - online
[18:44:49] Event: spark/status - offline
[18:44:51] Event: spark/status - online
[18:45:00] Event: spark/status - offline
[18:45:03] Event: spark/status - online
[18:45:13] Event: spark/status - offline
[18:45:16] Event: spark/status - online
[18:45:26] Event: spark/status - offline
[18:45:29] Event: spark/status - online
[18:45:40] Event: spark/status - offline
[18:45:43] Event: spark/status - online
[18:45:52] Event: spark/status - offline
[18:45:56] Event: spark/status - online
[18:46:04] Event: spark/status - offline
Next up, bisections... but that will probably have to be a job for tomorrow. I'll shut up for now! :o ;D
EDIT3: I know I said I'd shut up... but this is important... one of the oaks started offlining and onlining even in safe mode, and wouldn't co-operate... so I oak-restored it and it made no difference at all once it had done the update and been configured - it went config mode, no user rom found and back to it's old tricks. I did a serial upload, and it kept doing it, and then finally triggered a 'spark/status/safe-mode' event again before starting the user sketch properly. I'm chalking this up to a fault on the sparkfun servers for now, as this is on the 1.0.1 config that was working perfectly fine until just now.
-
PeterF's experience is probably dissuading other people from trying 1.0.4, but if you have tried it, I'd be very interested to know if you have experienced the same issues he has.
-
PeterF, that is very odd.
As far as I can tell, the spark/status/safe-mode event is being generated by the Cloud using data sent by the Oak (https://github.com/digistump/OakCore/blob/master/cores/oak/OakParticle/particle_core.cpp#L1067-1073) in response to the DESCRIBE request in the Particle Cloud handshake. However, the weird thing is that this data appears to be sent every time any Oak connects to the Cloud, and this part of the code is the same in 1.0.4 as it is in 1.0.1, yet I've never seen this message before.
One other question. I'm not sure if you had a chance to check, but after the safe-mode event and the sketch started running, where you able to upload code OTA?
-
I couldn't say earlier, as as I mentioned in EDIT3 above, at least one of the two test subjects started it's endless online offline loop after entering safe mode, and even after a fresh firmware wipe over serial (using the firmware image downloaded last night from https://oakota.digistump.com/firmware/firmware_v1.bin (https://oakota.digistump.com/firmware/firmware_v1.bin)), which is why I'm pointing the finger squarely at the particle server ATM.
I just tried again with subject 1 (Oak5), and after triggering spark/status/safe-mode and running the user code properly, it was OTA programmable. I'm still waiting on the second test subject (Oak4) to become responsive... LATER: Had visitors, so it had time to trip. Oak4 also programmed once the user program was running (blink sketch). It is now doing the offline/online loop, so I expect to see it running normally soon.
-
To test out my theory of particle connection being the issue, I changed the blink sketch to have SYSTEM_MODE(SEMI_AUTOMATIC) to disable to particle connection, and it burst into life instantly after programming without any hiccups. So my recent gremlins are definitely particle-connection related, and aren't specific to 1.0.4 - this is an issue with 1.0.1, and also safe mode with system version 6. This is repeatable with both oaks that I have been testing.
However, two other oaks which are deep-sleep rebooting every 10 minutes are connecting fine, and a third with an active 24x7 connection is also fine. I haven't tried programming them recently, so I don't know if there is any connection there (they are probably running 0.9.5 or 1.0.0 still FWIW).
I extended the blink sketch slightly (as included below) to start up in semi_automatic mode, blink 10 times at 1 second intervals, then do 10 rapid flashes, and then try to connect. I got 10 slow flashes, 10 fast, and then device online and offline loops immediately after the faster flash (so on Particle.connect).
SYSTEM_MODE(SEMI_AUTOMATIC)
// the setup function runs once when you press reset or power the board
void setup() {
// initialize digital pin 1 as an output.
pinMode(1, OUTPUT);
for(int i = 0; i < 10; i++)
{
digitalWrite(1, HIGH); // turn the LED on (HIGH is the voltage level)
delay(1000); // wait for a second
digitalWrite(1, LOW); // turn the LED off by making the voltage LOW
delay(1000); // wait for a second
}
for(int i = 0; i < 10; i++)
{
digitalWrite(1, HIGH); // turn the LED on (HIGH is the voltage level)
delay(100); // wait for a second
digitalWrite(1, LOW); // turn the LED off by making the voltage LOW
delay(100); // wait for a second
}
Particle.connect();
}
// the loop function runs over and over again forever
void loop() {
digitalWrite(1, HIGH); // turn the LED on (HIGH is the voltage level)
delay(1000); // wait for a second
digitalWrite(1, LOW); // turn the LED off by making the voltage LOW
delay(1000); // wait for a second
}
-
PeterF and kh - thank you both for all the analysis and troubleshooting, PeterF's findings gave me an idea that this might be related to the cloud system update functions which we aren't currently using, I wonder if Particle made a change to how these work to improve their devices and that started triggering these loops
If you can please try 1.0.5 which strips these functions out for now and tells Particle "no update needed" whenever it asks
Thanks!
-
Unloaded 1.0.1, and loaded 1.0.5; re-tried the start code. Failed to program 3 times; last time I tried a power on pin 1 ground. It's claiming 1.0.2 version:
"C:\Users\sysadm\AppData\Local\Arduino15\packages\digistump\tools\esptool2\0.9.1/esptool2.exe" -quiet -bin -boot2 -4096 -iromchksum "C:\Users\sysadm\AppData\Local\Temp\buildb617f2b2b4ed5d187612b5a5a49a2d5d.tmp/StartTimer.ino.elf" "C:\Users\sysadm\AppData\Local\Temp\buildb617f2b2b4ed5d187612b5a5a49a2d5d.tmp/StartTimer.ino.bin" .text .data .rodata
Sketch uses 260,007 bytes (24%) of program storage space. Maximum is 1,040,368 bytes.
Global variables use 51,140 bytes (62%) of dynamic memory, leaving 30,780 bytes for local variables. Maximum is 81,920 bytes.
OakCLI tool version 1.0.2
Using config file at: C:\Users\sysadm\AppData\Roaming\oak\config.json
Sending file to cloud, to flash xxx (Device ID: zzz)
Error : An error occurred while flashing the device:
-
Had been working to see which of 1.0.1 to 1.0.4 would work for me. After a serial restore to 1.0 and update to 1.0.1 I was having decent results with a couple different sketches.
These had been working before things fell apart for me, so your theory on the Spark system trying to force an update seems to fit. I was focusing on Spark/Particle limits, since I was having trouble with any sketch staying connected for long -- even on 1.0.1. With nothing more than a 8 sec time between particle.publish events, I seemed to stay on line w 1.0.1.
Had earlier used a 15 sec SimpleTimer setup for a sketch publishing to both Particle and to Blynk. That didn't seem to work so well these days. Decent results if writing to Particle or using a Yield() every 6 to 10 sec. Was going to refine this down when I tried it w 1.0.5. No problems w 12 second or greater Simple Timer driven loops. OTA updates become routine vs try many time till I got lucky (power cycling etc to try and hit an OnLine window to catch a flash).
With 1.0.5,- OTA updates seem to hit every time
- I stay connected to particle cloud with minimal overhead out to at least 15 sec pauses between actions
- Sketch with both particle.Publish and Blynk controls working again
- I may put my serial programing setup away for awhile
I think you nailed the biggest culprit here and since some of my sketches had worked on 1.0.2 or 1.0.3 earlier, I also suspect that changes on the Spark/Particle end may have been the culprit.[/b][/size]
Can we get an updated image to load via the serial restore procedure or at least fold this fix back into the first OTA update after factory restore? Having had to master the Serial restore process in order to keep my Oaks functional, I would appreciate getting to a more refined baseline (like 1.0.5 maybe?) -- or instructions of how to extract or obtain the appropriate binaries from the various cores we have -- after a serial restore. (thanks for the windows exe tool to do the serial restore. works well)
It will be good to get back to using vs troubleshooting. Cheers
James
-
Woohoo... winner winner chicken dinner! Where do I send the chicken? ;D ;D :o
I just update my test computer to 1.0.5, and everything is back to normal... or even better than before!
When do you think you'll push through an update to oakota.digistump.com/firmware so that safe/config mode also gets that patch?
[19:21:22] Device change: Oak5
//upload a simple blink sketch - 1.0.5
[19:21:49] Event: spark/flash/status - started
[19:22:10] Event: spark/status - offline
[19:22:10] Event: spark/flash/status - failed
[19:22:50] Event: spark/status - online
//fantastic start!
//upload another sketch I have been working on... the MQTT one...
[19:24:31] Event: spark/flash/status - started
[19:24:53] Event: spark/status - offline
[19:24:53] Event: spark/flash/status - failed
[19:24:59] Event: spark/status - online
[19:25:11] Event: MQTT ledStatus sketch starting... - null
//great... it started straight away and said it is online!
//what about a power cycle?
[19:28:08] Event: spark/status - online
[19:28:20] Event: MQTT ledStatus sketch starting... - null
//now for the moment of truth... is it a fluke, or has 1.0.5 fixed all? Flash blink sketch with 1.0.1 again.
[19:28:57] Event: spark/flash/status - started
[19:29:19] Event: spark/status - offline
[19:29:19] Event: spark/flash/status - failed
[19:29:25] Event: spark/status - online
[19:29:35] Event: spark/status - offline
[19:29:37] Event: spark/status - online
[19:29:46] Event: spark/status - offline
[19:29:47] Event: spark/status - online
[19:29:57] Event: spark/status - offline
[19:29:59] Event: spark/status - online
[19:30:00] Event: spark/status/safe-mode - {"f":[],"v":{},"p":82,"m":[{"s":1040368,"l":"m","vc":30,"vv":30,"f":"s","n":"1","v":6,"d":[]},{"s":1040368,"l":"m","vc":30,"vv":30,"u":"0","f":"u","n":"1","v":1,"d":[{"f":"s","n":"1","v":6,"_":""}]}]}
//yup, it didn't like that 1.0.1 blink sketch, lets get it back on 1.0.5 pronto!
[19:30:25] Event: spark/flash/status - started
[19:30:46] Event: spark/status - offline
[19:30:46] Event: spark/flash/status - failed
[19:30:52] Event: spark/status - online
[19:31:04] Event: MQTT ledStatus sketch starting... - null
//yay! it works!
-
Unloaded 1.0.1, and loaded 1.0.5; re-tried the start code. Failed to program 3 times; last time I tried a power on pin 1 ground. It's claiming 1.0.2 version:
OakCLI tool version 1.0.2
The OakCLI tool version 1.0.2 is normal - that tool isn't updated as much as the system core is, so it's version hasn't changed.
My apologies if you have commented on this in another thread... but what does your Oak say when you look on the Particle Dashboard (https://dashboard.particle.io/user/devices), or have a look at it on OakTerm (http://digistu.mp/oakterm)? What I'm particuarly after here is to see if it is doing the offline/online cycle mine was. To see that on Particle, you'll need to look at the Logs section (https://dashboard.particle.io/user/logs), as the main dashboard will say the oak is online the whole time (IIRC, a device is considered still online if it said it was within the last 15 seconds).
If you have the same problem, leave the oak powered up and wait for the spark/status/safe-mode event to trigger. You'll then be able to flash your Oak again, and compile a sketch with 1.0.5, which should fix it. Unfortunately, as this appears to be a symptom of a recent change on the Particle system related to system updates, it also knocks out safe/config mode the same way, so the only solution I have found so far is to simply wait for it to stop cycling. Fingers crossed!
-
I let one of my oaks cycle on/offline until it got to safe mode. However, oakcli does not see it even though it list in Particle CLI. Is serial programming my only option?
-
When you say oakcli doesn't see it, do you mean that it won't program, or its not listed as a device to program when you run oakcli?
-
Thanks PeterF and DrJFM for testing - great news!
Attached is a new system image using this build that can be loaded over serial using this command:
python esptool.py --baud 115200 --port YOUR_COM_PORT write_flash -fs 32m 0x1000 blank.bin 0x2000 firmware_v1.bin 0x101000 blank.bin 0x102000 blank.bin 0x202000 blank.bin
I'm calling it a night and I haven't tested it completely which is why I'm not updating the first update server with it yet - but feel free to give it a spin and please let me know if you do.
@pkourany - once we confirm this new system image works well we'll update the system update server with it and publish a wiki on how to force an OTA update of the system image - tomorrow hopefully - until then serial is the fastest route
-
Thanks admin! As a Particle Elite I feel like a noob with the Oak! As a backup I now have to find my 3.3v FTDI... somewhere around here... :o
-
Any news on this?
-
PeterF; OakTerm works great! Very insightful. So, the oak was cycling online/offline, and it wouldn't program....after 5 minutes, it went into safe mode (and printed lots of stuff) . Then it programmed successfully; blink program works with correct timing; I power it off and on, and it boots into the program just fine. :-)
-
@pkourany: I have finally had some time to test the test firmware that Erik uploaded, and it seems to be working great on my two test subjects. I'll now be proceeding to roll it out to my other three Oaks before they start to play up.
@aztorell: great to hear! Yes, OakTerm is a great tool... kh's hard work on this is greatly appreciated!
Below is are my logs from testing my two Oaks. They were programmed using my main machine (on Windows 10 with Arduino IDE 1.6.9) which is now on board version 1.0.5. Long story short, they tested out perfectly. However, the logs for both Oaks are below so you can see for yourself :D
If it makes any difference, I am using the 'Pin 1 Safe Mode, Manual Config Only' board variant. If you think that alters anything, I am happy to repeat the tests again using 'Pin 1 Safe Mode, Default'.
Oak5 - test subject 1
# Run Oak5 without changing code loaded two days ago with 1.0.5 (MQTT listener sketch)
[11:22:01] Device change: Oak5
[11:22:06] Event: spark/status - online
[11:22:18] Event: MQTT ledStatus sketch starting... - null
# Worked perfectly. Power off Oak, waited until it was reported as offline, and then switched it on again.
[11:23:34] Event: spark/status - offline
[11:23:54] Event: spark/status - online
[11:24:06] Event: MQTT ledStatus sketch starting... - null
# updated oak with forum system firmware file
esptool --baud 115200 --port COM8 write_flash -fs 32m 0x1000 blank.bin 0x2000 firmware_v1.bin 0x101000 blank.bin 0x102000 blank.bin 0x202000 blank.bin
# updated, just checking configuration, it now reports as being system version 10, and remembered wireless settings
[11:31:32] Event: spark/status - online
[11:31:44] Config Mode
[11:31:45] No user rom found
#uploading plain blink sketch, with only change being changing 13 to 1 ;)
[11:37:45] Event: spark/flash/status - started
[11:38:06] Event: spark/status - offline
[11:38:06] Event: spark/flash/status - failed
# I think Oak crashed on reboot (no power cycle after system update glitch?), so I power cycled it and it was ok, blink sketch worked perfectly.
[11:38:49] Event: spark/status - online
# now to try my MQTT listener sketch as something slightly more demanding
[11:41:01] Event: spark/flash/status - started
[11:41:21] Event: spark/status - offline
[11:41:21] Event: spark/flash/status - failed
[11:41:27] Event: spark/status - online
[11:41:39] Event: MQTT ledStatus sketch starting... - null
#sketch is working as expected, didn't have to touch power, everything looks good!
Oak 4 - test subject 2
[11:42:58] Device change: Oak4
# power up Oak4 with previously running 1.0.5 code to see how it is responding... blink sketch, working fine
[11:43:21] Event: spark/status - online
# updated oak with forum system firmware file
[11:45:04] Event: spark/status - offline
esptool --baud 115200 --port COM8 write_flash -fs 32m 0x1000 blank.bin 0x2000 firmware_v1.bin 0x101000 blank.bin 0x102000 blank.bin 0x202000 blank.bin
# updated, checking configuration, it also reports as being system version 10, and remembered wireless settings
[11:47:12] Event: spark/status - online
[11:47:24] Config Mode
[11:47:24] No user rom found
# uploading plain blink sketch, with only change being changing 13 to 1 ;)
[11:49:39] Event: spark/flash/status - started
[11:50:01] Event: spark/status - offline
[11:50:01] Event: spark/flash/status - failed
# Oak crashed on reboot (no power cycle after system update glitch?), so I power cycled it and it was ok, blink sketch worked perfectly
[11:50:17] Event: spark/status - online
# don't know why it did this cycle, but it is stil working fine.
[11:50:26] Event: spark/status - offline
[11:50:27] Event: spark/status - online
# now to try my MQTT listener sketch as something slightly more demanding
[11:53:21] Event: spark/flash/status - started
[11:53:42] Event: spark/status - offline
[11:53:42] Event: spark/flash/status - failed
[11:53:48] Event: spark/status - online
[11:53:59] Event: MQTT ledStatus sketch starting... - null
# again, sketch is responding as expected! 2 for 2!
-
Have tried the serial based update to 1.0.5 and various other firmware related trials and will relate my experience/conclusions here:
Trying to get ready to test the serial update, I managed to get an Oak to a place where it wouldn't update OTA anymore -- and I was not trying yet -- just getting ready to test serial update posted by Admin. So...flashed the firmware and had a functional Oak again! Thanks, Eric
Then, more systematically, went to 1.0.2 and back via the Arduino Board Manager. Both would load and reload OTA sketches. The OakTerm really helps follow painlessly. Thanks KH.
Tried 1.0.3 and ended up having to do a factory restore. After serial flash to factory restore state, I didn't succeed in an immediate second Serial Flash to 1.0.5. Had to do the Serial Factory restore flash, Config the SSID and password and manage the first Particle OTA update.
From there I could use IDE board manager. 1.0.3 is to be avoided IMHO.
Following this serial factory to 1.0.5 via OTA w IDE Board Manager, I went to 1.0.2, then used the serial update to go to 1.0.5. Flashed 1.0.5 twice. After first, Oak was showing Config. Mode and didn't want to flash w serial. Grounded Pin1 and Pin2 both during flash to 1.0.5. Conclusion -- looks like if you are moderately non-functional and three blinking in config mode but can't upload, the serial flash to 1.0.5 will be a fix -- faster than full factory + OTA first update. (I will try the one, 2 flash of factory + 1.0.5 update again w possible use of Pin 1 to Ground on second serial flash -- or shouldn't this get me to a useful state anyway?
If the device is not too messed up and the serial flash to 1.0.5 works, a benefit is that it did not wipe my SSID and password. Unit came up and logged back on in Config Mode and took a OTA sketch.
For example once 1.0.5 is running, I went to(a) 1.0.2 with Board Manager and ran a Temp/Humidity sketch to (b) a simple test sketch in 1.0.2 (editing sketch to list version in Particle.println statement), then(c) reloaded this simple sketch using 1.0.5 via Board Manager and (d) back to my Blynk enabled Temp/Humidity sketch in 1.05 all within a bit over 10 min OTA (timelines below).
I suspect that if you generate an error or two in 1.0.2, you end up unable to recover as readily as does 1.0.5, but can't state that as fact.
I find 1.0.3 to be about a one sketch firmware and to be avoided.
The 1.0.5 firmware continues to be well behaved and robust for me
I may have had the odd need to use a Pin 1 reset to config mode, power cycle or 2 upload tries to succeed, but generally, everything recovers well.
If Particle says the OTA Flash succeeded (I saw this a few times) it failed.
If Particle says the OTA Flash failed, it is usually a good sign and it worked -- can we get the logic on the return code inverted for OAK flashes?
If the Flash dots ie Flashing............................................................................... go much longer than that, it is almost always a fail.
Same for the reboot dots.
If we get another buggy core release, please don't pull all the files. We were left without the ability to regress to 1.0.2 -- which still works decently for me. Perhaps something like 1.0.3 could be substituted with a prior release such as 1.0.2 (ie a copy renamed 1.0.3 with appropriate checksum for the IDE) to prevent additional bricking.
I use an processor removed UNO to do the serial flashes. I have had occasionally to move the UNO to OAK ground to a different ground socket on my OAK or wiggle it in real well and have benefited a bit (I believe) by cleaning up my solder joints at all the ground pins and Vin Vcc etc.) I have had great serial flashing success using the 3.3V output on UNO to the Vcc points on the OAK and Ground to Ground to power the Oak from UNO. I like having a common ground and everything powers up at once. I use a USB3 port on my Desktop to assure I have adequate power and have also used an external power supply to the UNO (but not lately -- might be better w USB 2 connection).
As always, your mileage may vary.
James
[23:50:39] Event: spark/flash/status - started
[23:50:54] Event: spark/status - offline
[23:50:54] Event: spark/flash/status - failed
[23:51:02] Event: spark/status - online
[23:51:22] % RH = 55.2
Temp = 20.9
[23:51:37] % RH = 57.4
Temp = 20.4
[23:51:52] % RH = 57.6
Temp = 20.4
[23:52:07] % RH = 57.8
Temp = 20.3
[23:52:22] % RH = 58.0
Temp = 20.3
[23:52:37] % RH = 58.2
Temp = 20.3
[23:52:52] % RH = 58.3
Temp = 20.2
[23:53:07] % RH = 58.4
Temp = 20.2
[23:53:22] % RH = 58.6
Temp = 20.2
[23:53:37] % RH = 58.8
Temp = 20.1
[23:53:52] % RH = 59.0
Temp = 20.1
[23:54:07] % RH = 59.1
Temp = 20.1
[23:54:22] % RH = 59.1
Temp = 20.1
[23:54:37] % RH = 59.2
Temp = 20.0
[23:54:52] % RH = 59.4
Temp = 20.0
[23:55:05] Event: spark/flash/status - started
[23:55:21] Event: spark/status - offline
[23:55:21] Event: spark/flash/status - failed
[23:55:28] Event: spark/status - online
[23:55:44] Event: Hi! - w 15 sec timer
[23:55:44] Hi using 1.0.2 loop#1
[23:55:59] Event: Hi! - w 15 sec timer
[23:55:59] Hi using 1.0.2 loop#2
[23:56:14] Event: Hi! - w 15 sec timer
[23:56:14] Hi using 1.0.2 loop#3
[23:56:29] Event: Hi! - w 15 sec timer
[23:56:29] Hi using 1.0.2 loop#4
[23:56:44] Event: Hi! - w 15 sec timer
[23:56:44] Hi using 1.0.2 loop#5
[23:56:59] Event: Hi! - w 15 sec timer
[23:56:59] Hi using 1.0.2 loop#6
[23:57:14] Event: Hi! - w 15 sec timer
[23:57:14] Hi using 1.0.2 loop#7
[23:57:29] Event: Hi! - w 15 sec timer
[23:57:29] Hi using 1.0.2 loop#8
[23:57:44] Event: Hi! - w 15 sec timer
[23:57:44] Hi using 1.0.2 loop#9
[23:57:59] Event: Hi! - w 15 sec timer
[23:57:59] Hi using 1.0.2 loop#10
[23:58:14] Event: spark/flash/status - started
[23:58:29] Event: spark/status - offline
[23:58:29] Event: spark/flash/status - failed
[23:58:37] Event: spark/status - online
[23:58:52] Event: Hi! - w 15 sec timer
[23:58:52] Hi using 1.0.5 loop#1
[23:59:07] Event: Hi! - w 15 sec timer
[23:59:07] Hi using 1.0.5 loop#2
[23:59:22] Event: Hi! - w 15 sec timer
[23:59:22] Hi using 1.0.5 loop#3
[23:59:27] Event: spark/flash/status - started
[23:59:46] Event: spark/status - offline
[23:59:46] Event: spark/flash/status - failed
[23:59:53] Event: spark/status - online
[00:00:13] % RH = 59.4
Temp = 20.0
[00:00:28] % RH = 60.3
Temp = 19.8
[00:00:43] % RH = 60.3
Temp = 19.8
-
once we confirm this new system image works well we'll update the system update server with it and publish a wiki on how to force an OTA update of the system image - tomorrow hopefully - until then serial is the fastest route
Wanted to just chime in and say I finally had success with this firmware flashing over serial, then re-running the initial setup. Thanks!!
-
...but also I am not having any success with an Oak that was previously claimed, then un-claimed. from /info/:
{
"id": "REDACTED",
"claimed": 0,
"claim_code": "REDACTED",
"server_address_type": 1,
"server_address_domain": "device.spark.io",
"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",
"first_update_fingerprint": "98 66 d5 5c 3d 4a 49 24 e3 1b 72 8b 8f 2e 65 2e 32 2a 7b 95"
}
Any suggestions? Attempting to claim via Particle's site fails, as well as the initial setup.
-
Just got back from vacation and am catching up on posts...
Yes, OakTerm is a great tool... kh's hard work on this is greatly appreciated!
OakTerm really helps follow painlessly. Thanks KH.
Thanks! Glad you find it useful. I'd be remiss if I didn't mention @emcniece. He hasn't been active on the forums lately, but he contributed just as much to OakTerm as I did.
-
I haven't touched my oak in several months and am trying to catch up on all the new stuff, prompted by the Kickstarter update. My read of that seemed like once I update the Oak version in the arduino board manager and flash a sketch, the firmware should be updated. Is that correct?
I removed Digistump Oak via the board manager, and even deleted .arduino15/packages/digistump entirely, then re-install 1.0.5 from the boards manager. I can upload a blink sketch just fine, but when I jump p1 to gnd and connect via wifi, I still show system_version as "6" and version_string as "1.0.0."
What triggers the updated firmware or am I misunderstanding how this should work?
-
'fraid to tell you mate, you got it wrong! :o 8)
Ok, so what has happened is since you've updated the boards package, your code is now being compiled with firmware 1.0.5, as the Arduino IDE generates it every time you compile. So the version of the user rom part of the Oak reflects whatever version of the package you're using.
The safe/config mode side of things isn't touched though. Erik said he would be posting instructions on how to trigger an OTA firmware update, but he seems to have gone quite on us atm (so hopefully he hasn't been hit by a bus, and is locked in mortal combat with Particle to get things working on that front... er, but I digress).
So, to get your config mode code up to scratch, you need to do a serial update. You 'could' do the OakRestore thing (https://github.com/digistump/OakRestore#force-update-an-oak) and then the Oak will grab the current safe-mode firmware package, but it's much quicker and easier to just do the forced serial update mentioned at the bottom of the OakRestore instructions (https://github.com/digistump/OakRestore#force-update-an-oak), as it will just work.
Rather interestingly, it will then report as system_version 10, but the version string will be 1.0.5 (due to how the version string is formed - major version 10, minor version 6, thus 106, but only the major version is shown as the system version).
-
Thanks, PeterF. I guess I'm not familiar with the lingo. Does everyone know what "config mode" means? I think this is one of the most challenging aspects of the Oak for me, namely that there are a lot of sort of "tricky" documentation details that are not intuitive to find. I have a really hard time explaining why... naming conventions, where they're put on the wiki, just not sure! I can only say that it's tough for me to follow what exactly means and does what in what situation.
I went back to check the Kstarter update and indeed, it says: "All newly provisioned devices will get this in their first update. All devices already in use will get these fixes for all new sketches (if you update your Arduino IDE Oak Package from the Boards Manager), but not for config mode."
From a user's standpoint, though, it's not clear to me what "safe/config" mode is. I just *use* the Oak. I connected it back in March, it got the firmware update, and then I started programming with it. Are you saying "safe/config mode" is the mode in which I'm connected to it via wifi, with it as the hotspot (vs. it being connected to the cloud through another internet source)? If so, I guess that makes sense.
Still totally not getting the version thing.
- system_version: 10
- version string: 1.0.5
- major version 10
- minor version 6
- thus, 106
Or did you mean all of those 6's to be 5's (that would then make sense to me)? :) Thanks for the input/handholding/help!
-
Er... yes, I did... sorry about that... where I wrote 6 I meant 5... I'll go back and edit that to clear that issue up... last thing you needed was yet another thing to confuse you! :D
And the short answer is yes (but to what you may ask?). When you run the oak normally (after it has been programmed), it runs the user rom/program. When you jumper P1 to GND (ground), it boots into safe/config mode instead. You could call it config mode, but it gets a bit more complicated than than when it is in the 'default' mode (selected from the Arduino IDE Boards list), as that mode allows the Oak to reboot into config mode when it looses it's connection to Particle for more than a few minutes, and to also boot into config mode when the user rom code stuff something up. Hence the dual config/safe mode terminology.
One point that sometimes confuses is that the config/safe mode both connects to particle waiting a new user rom/program, AND also sets up the Acorn access point, allowing you to change which wireless network the Oak connects to. However , you don't need to reconfigure the Oak via the Acorn network unless you want to change that setting - it remembers the last network it was connected to still.
Just think of the oak as having two modes - one with the jumper on P1/GND, and one without. The one without the jumper will always be the version of the firmware you compile your code with. The one with the jumper will be whatever version was current when you provisioned the device (for now at least), unless you do a serial firmware update to manually update it.
Is that starting to make sense yet? I won't start :'( yet if it isn't. ;D
-
Peter,
I don't get the difference in these modes either, so really interested to read your description above and attempt to make sense of it all. I'll try to put your description into my own words to see if I've understood correctly what you are saying. :o
I think you are saying that the Oak has two copies of the firmware:
- The first copy is the config mode / safe mode copy that was put on when the device was first configured. This is the firmware used:
- when the device has no sketch installed
- when the device has wifi problems
- when the device has particle-cloud problems
- or when safe mode is triggered using pin1 at boot
And this firmware isn't currently updated (unless done manually by serial). In the near future we'll be able to update this firmware OTA, but until then it might be running an older version than the second firmware below - The second copy of the firmware is like a "runtime firmware" (does it have an official name?). It gets chosen with the sketch at upload time, and is loaded with the sketch to run that sketch (and all the behind the scenes features!). This is more likely to be the latest firmware as there is probably little reason to run an older copy. It is a new copy of the firmware loaded with each sketch, so is regularly replaced. This is the copy of firmware that runs most of the time (unless one of the conditions above is triggered to run the config firmware)
Is this roughly correct? (Marks out of 10?)
It is pretty complex to get your head around, but I guess you need a firmware running all the time to be able to load a new sketch and firmware with it, so you end up having to have multiple copies.... particularly needing the safe mode / config mode to fallback to if the sketch loaded fails.
-
Will 9 / 10 make you happy? Can't give you 10 else there could never be anything better!! ;D ;D
That why I understand it to have three parts (one of which I havn't mentioned yet, so I will now).
When you power on the Oak, the first thing that happens is the bootloader (OakBoot) runs. It's job is to decide what firmware to run. If the Oak crashed, it runs the safe mode firmware. If Pin 1 is connected to GND, it runs the safe mode firmware. Otherwise, it runs your sketch, which is loaded into (another firmware slot).
Everything you said in 1 applies when the safe mode firmware is run.
Only niggle I have with 2 is that when your sketch is run, it runs your program, plus has the particle connect stuff running in the background - which is extra stuff added into your sketch to allow the 'magic' to happen. It's a bit like how when you use the setup and loop functions in the Arduino IDE, a lot more is compiled in to make things that simple.
-
@PeterF: That helped a lot. I think I get it now: jumper p1 vs. other. That said, it looks like some back and forth since then added that one can force safe/config via jumping p1-gnd, but that it also is triggered by some things going "wrong." I'm going to guess this is what the Kickstarter update was trying to get at? Namely, that 1.0.5 has some improvements in how this works when things don't go well with particle or other things?
Like I said, I've never touched this in my code; I only use it if I want to change networks or when I updated the firmware on brand new oaks. I'm guessing post-firmware flash also triggers safe mode per emardee's point about "no sketch installed." In any case, I think I understand now. So would the advantage of no only flashing a new sketch (which updates the user firmware) but also forcing a safe/config mode firmware update be that there are, indeed, improvements to these "odd/problem" situations and how the oak reacts (i.e. to no wifi, inability to connect to particle, etc.)?
Thanks!
-
Will 9 / 10 make you happy? Can't give you 10 else there could never be anything better!! ;D ;D
I'll be very very happy with 9/10... I didn't think I understood it that well!
That why I understand it to have three parts (one of which I havn't mentioned yet, so I will now).
When you power on the Oak, the first thing that happens is the bootloader (OakBoot) runs. It's job is to decide what firmware to run. If the Oak crashed, it runs the safe mode firmware. If Pin 1 is connected to GND, it runs the safe mode firmware. Otherwise, it runs your sketch, which is loaded into (another firmware slot).
Ah, hang on, glad you said that.... that jogs a memory of something Erik said a while back... something about the 4MB of ram actually being divided in 4 slots of 1MB (I think he said that?). Is that related to this? (Man this is even more complex than I thought - but shows the thought and careful design Erik put into the original design and concept!)
Everything you said in 1 applies when the safe mode firmware is run.
Yay!
Only niggle I have with 2 is that when your sketch is run, it runs your program, plus has the particle connect stuff running in the background - which is extra stuff added into your sketch to allow the 'magic' to happen. It's a bit like how when you use the setup and loop functions in the Arduino IDE, a lot more is compiled in to make things that simple.
When you said "allow the 'Magic' to happen".....that is what I meant by "run the sketch and all the behind the scenes features!".... but you made it clearer and more explicit... which is useful in a thread like this, as describing the same thing in a few different ways helps the knowledge be understood by more people! (different bits will help different people).
I think it is worth mentioning manual mode and advanced mode (as in the 3 choices you have at upload time alongside the normal operation we've talked about above). If I understand this correctly manual mode lets you cause the Oak to ignore wifi problems and particle cloud problems, and keep running the the runtime sketch and firmware anyway. So if you choose manual mode, only "no sketch" or "pin1 to gnd" are left as triggers to take you into config/safe mode (and there must be a sketch as you choose this option when loading a sketch, so in reality only "pin1 to gnd" is left as the trigger). There is a third mode marked advanced, which further disables "pin 1 to gnd" as well, and since you only get to choose this when loading a sketch "no sketch" doesn't apply as a reason either, so is safe/config mode completely disabled then? (what does that mean though..... presumably it means if anything goes wrong you need to do a serial upload or is there another way?)
Is that your understanding of those features (it is a bit vague in my head, and I might have used the wrong terminology)?
Perhaps we ought to be refining these descriptions into the wiki somewhere?
-
I thought I should add the OakBoot bit to the discussion as that would help explain how the Oak decides to go into safe mode or into the user rom.
Yes, the Oaks memory is divided into multiple slots. How many I can't remember. if you were to say three (or four) slots, the safe mode firmware occupies slot #1, the firmware for your current running sketch occupies slot #2, and the next sketch you download goes into slot #3, and then becomes the active slot. This means slots 2 & 3 alternate between being the currently running sketch and the one being downloaded. This is how when a sketch download fails the Oak can reboot and go back to the last sketch you loaded onto it.
I was going to mention the Default, Manual and No Safe Mode options in my last reply, but thought I'd keep it short and sweet to keep it on topic. But yes, your summary is pretty much it.
Default will cause the Oak to reboot into safe mode if the wireless is down for more than a few minutes, looses it's connection to particle, or your code encounters a nasty error that doesn't lock the Oak up entirely which it can reboot out of, and of course the P1 to GND jumper on power up.
The Manual Config mode takes the wireless connection (and particle connection??) safe mode triggers out of the equation, meaning it is only code errors and the P1 to GND that should trigger it.
The No Safe mode option does appear to entirely disable safe mode, and you can't even do a P1 -GND power-on trigger. I need this for one of my Oaks, out of the five I have have running 1.0.5, it is being a problem child and keeps rebooting into safe mode with no apparent reason (it has always been a problem child though, so it doesn't really surprise me). After I put the No Safe mode variant on, it appears the only way I'll be able to re-enable safe mode is to follow the OakRestore or forced serial update instructions to do a 'factory restore' of the Oak. EDIT: This is only if the Oak crashes. As long as OTA programming is still working, you can upload a new program to the Oak with one of normal safe mode options, and it will be re-enabled.
I usually run all my Oaks in Manual Config mode as they are independently powered, meaning they will remain online when there is a power or internet outage, and I don't want them to all reboot into safe mode and make me have to go upload their programs to them again to get them to start working again.
And yes, that is probably a good idea... some sort of overview of the Oak memory structure and configuration options is indeed needed on the Wiki! :D