Firmware 1.0.2 kills my oaks Wifi and sketches

[boneskull]

...but also I am not having any success with an Oak that was previously claimed, then un-claimed.  from /info/:

Code: [Select]

{
  "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.

[kh]

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.

[jwhendy]

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?

[PeterF]

'fraid to tell you mate, you got it wrong!   

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 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, 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). 

[jwhendy]

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!

[PeterF]

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!

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. 

[emardee]

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. 

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.

[PeterF]

Will 9 / 10 make you happy? Can't give you 10 else there could never be anything better!! 

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.

[jwhendy]

@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!

[emardee]

Will 9 / 10 make you happy? Can't give you 10 else there could never be anything better!! 

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?

[PeterF]

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!