Arduino: Board oak1 is unknown

[who]

Hi,

I wanted to start with the first example program, but I get this error message in the Arduino IDE:

Code: [Select]

Arduino: 1.6.8 (Linux), Board: "Oak by Digistump (Pin 1 Safe Mode - Default), 80 MHz, Particle OTA, OAK (4M/1M SPIFFS), Single - 1MB (Fullsize)"

Board oak1 (platform oak, package digistump) is unknown

Error compiling for board Oak by Digistump (Pin 1 Safe Mode - Default).

Steps I have already done:
-downloading firmware and setting up Oak (http://rawgit.com/digistump/OakSoftAP/master/config.html)
-Oak is able to connect to particle cloud (I see the device ID on the particle website)
-setting up Arduino ID with this HowTo: http://digistump.com/wiki/oak/tutorials/arduino (also OakCLI)

But this is'nt working anyway.

Best wishes

[clovisf]

I'm getting the same in here!. If I happen to find any answer to that, will be posting here.

[who]

ok, solved the problem. We have to use Arduino 1.6.7, with 1.6.8 I am getting the error message from above

[digistump]

This is a bug in the Arduino IDE (so we have no power to fix it) - it is a known bug and occurs with 3rd party boards somewhat randomly in all versions above 1.6.5 which is why we recommend 1.6.5

[PeterF]

I had that problem at one point, and I hadn't updated or changed my Arduino 1.6.7 install (which is now 1.6.8 without any issues either... yet!). Appeared to be more related to json config file on the digistump server having been updated with a new version of the Oak core 'in place', rather than as a new version. I ended up simply removing the core in the board manager, as it was still listed there as installed, deleting the "%userprofile%\AppData\Local\Arduino15\packages\digistump\hardware\Oak" folder, emptying "%userprofile%\AppData\Local\Arduino15\staging" folder to make the IDE download the latest version of any needed files, and installing the Oak core again via the Arduino Board Manager. It hasn't missed a beat since.

[blurfl]

@pfeerick, your steps worked for me too. Thanks for showing the way.

[jwhendy]

Yeah, I wondered if something other than the IDE alone could cause the issue, and it sounds possible per @preerick's post. I'm on 1.6.8 on Linux and have had zero issues on the Arduino IDE side. All required troubleshooting has been related to wifi, updates, and particle association.

[driffster]

Yes the Arduino IDE as a tendency not to do proper updates if you already downloaded and install them on a previous version, I experienced it with 1.67. and 1.6.8. You have to delete the files manually like pfeerick said.

[defragster]

I was doing ESP8266_Generic on Arduino 1.6.7 - just went to 1.6.8 ( Extract the ZIP to a new directory ) - then put in the JSON string and it put on the OAK package no problem. Other ESP still works. A Different machine in Feb when I got my Beta board had 1.6.6 or 1.6.7 and worked well too.

[PeterF]

Hi defragster, are you talking about the generic ESP8266 core from https://github.com/esp8266/Arduino. If so, that behaves a bit differently again, as it has proper version tags, and you can pick from version 2.1.0, 2.0.0 and 1.6.5 when installing via the board manager. This versioning also allows the IDE to give you upgrade notifications that there is a updated board core available, instead of just falling flat in it's face with weird platform unknown messages

[defragster]

@pfeerick: Yes - like OAK - I used the specified JSON - the OAK's from Digistump and the one from the ESP8266 folks [updated to the 2.1].  Both are installed on my 1.6.8 system and I can program both without apparent problems - Again more widely tested on the generic - but I updated my seven oaks and pushed out a unique blink to them after getting them all Particle registered and CORE updated (using LOCAL) - and then set them aside for now.

http://arduino.esp8266.com/stable/package_esp8266com_index.json
http://digistump.com/package_digistump_index.json

ODD - and apparently harmless thing I checked with Digistump was that my Generic_ESP builds were using the OAK toolchain path.  If others find 1.6.8 to not work - I wonder if maybe there is something pulling from the Generic_ESP as well that helps my system use the OAK?  I saw a note about 'tool' update with the 2.1 Arduino_ESP8266, but on closer reading I think that is just a newer ESPTOOL.

In any case I'm using the 1.6.8 IDE to program either at will as indicated with no problem.  When I updated my first BETA OAK ( my last 6 were held up for the LiPo shield ) about a month ago - I did it under 1.6.7 and I saw the same behavior : it worked for the OAK, and it used the OAK toolchain on my Generic's when the ESP8266  was using the same ver 2.0 of the ESP8266.

[PeterF]

@defragster: Just wanted to make sure we were talking about the same core. Yes, the Oak and ESP8266 Arduino cores do share a lot of toolchain stuff - which is easy to see if you install one and then the other, as the Arduino IDE doesn't bother downloading the full toolchain, just the extra unique files needed for the core you are installing.

I run different versions of the Arduino IDE side by side - 0022, 1.0, and then every version from 1.6.5 to 1.6.8, and haven't had any issues with 1.6.6 to 1.6.8 with Oak, other than the same "Board oak1 (platform oak, package digistump) is unknown" error the OP reported, which was when I was running 1.6.7, and appeared to be connected with the change from 0.9.4 to 0.9.5 of the Oak core. Manual cleanup and reinstall of the Oak core fixed that. My upgrade from 1.0 to 1.0.1 when seamlessly this morning, so that was a good sign!

[defragster]

@defragster: Just wanted to make sure we were talking about the same core.  ...

When I wrote CORE - I meant the image that gets put onto the OAK - where the OAK unit gets the particle aware CORE, versus the standard ESP8266.

As far as the board manager code - my just OAK'd system already had the ESP8266 version 2.1 installed - then I installed the OAK JSON package with B.Mgr.  After that ESP8266 builds use the Digistump path. This told me that the whole of the OAK system was put on - then at compile time the IDE deferred to the more recent [but compatible] OAK source for the build tools.  This matches what I see on my other system when I did this in February.