Fatal Exception 28

[DarkLotus]

Ran Wifi Config, connected to cloud, received update. confirmed update with /system-version

I wiped out my 0.9 in ardunio and installed 0.9.1.

Built blink sample with Particle.delay. Flashed over the cloud then

Fatal exception (28): epc1=0x40001800, epc2=0x00000000, epc3=0x00000000, excvaddr=0x00637ff0, depc=0x00000000

I grabbed the boot output as well which is as follows:

ets Jan 8 2013,rst cause:2, boot mode:(3,7)

load 0x40100000, len 3632, room 16 tail 0 chksum 0xc0 load 0x3ffe8000, len 352, room 8 tail 8 chksum 0x82 csum 0x82

OakBoot v1 - N,BP,0

Tried grounding pin 10, but doesnt appear to change anything.

[DarkLotus]

Another update, only tested this on linux x64 but it appears to work ONLY changing compiler.cpp.flags to -O2. c.flags and c.elf.flags can stay as -Os

[ajpowell]

I have been reading this with interest - have been able to connect using esptool.py to my devices, but I am getting more consistent results from my desktop running Yosemite 10.10.5, than my laptop running El Capitan 10.11.2.

Was able to upload blank.bin and blank2.bin on 10.10.5...problems from 10.11.2 - I am able to connect using CoolTerm (using a Arduino USB2Serial) to see the Fatal Exception 28 messages on both, so maybe just esptool not liking El Capitan.

I'll dig more, but I am able to build (once changed compiler flags to -O2) on 10.11.2, but was unable to transfer. Using 10.10.5, I have been able to upload over serial connection to one of my bricked oaks with pin2 (SCL from diagram on KickStarter details) tied to GND - removing pin 2 GND wire and rebooting the oak gives the blink at the new rate (not quite the one listed above, on 100ms, off 4000 ms), but distinctive enough to know that it is the new code. I also see that the device has checked in on Particle dashboard too.

I do have a 3/4 dump of the ROM from before blanking if still useful.

The bin file compiled on 10.11.2 and was successfully uploaded on 10.10.5, is attached. oak_blink.ino.bin.zip

[nkildal]

I have also been following this with interest :smile:

I just tried the following - also on OSX El Capitan (10.11):

Changed compiler flags (all 3) from -Os to -O2, recompiled the blink example, uploaded to my Oak using esptool.py. On the terminal I still have exceptions, but they now look different.

Before (using -Os flags):

Fatal exception (28):
epc1=0x40001800, epc2=0x00000000, epc3=0x00000000, excvaddr=0x00637ff0, depc=0x00000000

Now (using -O2 flags):

 ets Jan  8 2013,rst cause:1, boot mode:(3,6)

load 0x40100000, len 3632, room 16 
tail 0
chksum 0xc0
load 0x3ffe8000, len 352, room 8 
tail 8
chksum 0x82
csum 0x82

OakBoot v1 - E,BU,0

Exception (28):
epc1=0x40223fc1 epc2=0x00000000 epc3=0x00000000 excvaddr=0x00000000 depc=0x00000000

ctx: sys 
sp: 3ffff8f0 end: 3fffffb0 offset: 01a0

>>>stack>>>
3ffffa90:  00000052 00000127 00000138 0000001f  
3ffffaa0:  00000138 00000000 3fff06c5 00000001  
3ffffab0:  40223fe8 40220dd4 00000006 00000000  
3ffffac0:  3fff05b2 3fff0580 00000001 00000001  
3ffffad0:  3fff05b2 40220dc0 00000006 0000000e  
3ffffae0:  00000001 00000000 00000002 40006784  
3ffffaf0:  00000000 3fff0570 00000000 402211cf  
3ffffb00:  00000000 3fff0570 00000006 00000001  
3ffffb10:  402211a7 3ffe82c0 3ffe82c0 2e2c2927  
3ffffb20:  00004d3f 402229f0 3fff0570 3fff06e4  
3ffffb30:  40222a05 3fff0570 3fff06e4 3fff0580  
3ffffb40:  3fff08c2 00000001 3fff06e4 3fff0580  
3ffffb50:  3fff0570 60000600 3fff0580 3ffffb80  
3ffffb60:  4021e7e3 00000000 00000000 3fff06e4  
3ffffb70:  401059c2 60000e00 402230ba 60000e00  
3ffffb80:  40223626 3ffffb90 00000008 40217a92  
3ffffb90:  00000010 3ffe83a0 00000000 000000d6  
3ffffba0:  00000000 00000000 00000000 3ffeb7e0  
3ffffbb0:  00019325 40206f39 3ffeb802 3fff4808  
3ffffbc0:  3ffeb802 3fff4778 0000007d 00000000  
3ffffbd0:  00000000 00000000 00000080 00000000  
3ffffbe0:  40101578 40101354 00000000 40218a8b  
3ffffbf0:  40218ef7 60000e00 3fff4808 40218edc  
3ffffc00:  40101f58 000003fd 0000001f 3fffffb0  
3ffffc10:  40001100 3fff4888 3ffeb802 40101f05  
3ffffc20:  ffffffff ffffffff ffffffff ffffffff  
3ffffc30:  ffffffff ffffffff ffffffff ffffffff  
3ffffc40:  ffffffff ffffffff ffffffff ffffffff  
3ffffc50:  ffffffff ffffffff ffffffff ffffffff  
3ffffc60:  ffffffff ffffffff ffffffff ffffffff  
3ffffc70:  ffffffff ffffffff ffffffff ffffffff  
3ffffc80:  ffffffff ffffffff ffffffff ffffffff  
3ffffc90:  ffffffff ffffffff ffffffff ffffffff  
3ffffca0:  ffffffff ffffffff ffffffff ffffffff  
3ffffcb0:  ffffffff ffffffff ffffffff ffffffff  
3ffffcc0:  ffffffff ffffffff ffffffff ffffffff  
3ffffcd0:  ffffffff ffffffff ffffffff ffffffff  
3ffffce0:  ffffffff ffffffff ffffffff ffffffff  
3ffffcf0:  ffffffff ffffffff ffffffff ffffffff  
3ffffd00:  ffffffff ffffffff ffffffff ffffffff  
3ffffd10:  ffffffff ffffffff ffffffff ffffffff  
3ffffd20:  ffffffff ffffffff ffffffff ffffffff  
3ffffd30:  ffffffff ffffffff ffffffff ffffffff  
3ffffd40:  ffffffff ffffffff ffffffff ffffffff  
3ffffd50:  ffffffff ffffffff ffffffff ffffffff  
3ffffd60:  ffffffff ffffffff ffffffff ffffffff  
3ffffd70:  ffffffff ffffffff ffffffff ffffffff  
3ffffd80:  ffffffff ffffffff ffffffff ffffffff  
3ffffd90:  ffffffff ffffffff ffffffff ffffffff  
3ffffda0:  ffffffff ffffffff ffffffff ffffffff  
3ffffdb0:  ffffffff ffffffff ffffffff ffffffff  
3ffffdc0:  ffffffff ffffffff ffffffff ffffffff  
3ffffdd0:  ffffffff ffffffff ffffffff ffffffff  
3ffffde0:  ffffffff ffffffff ffffffff ffffffff  
3ffffdf0:  ffffffff ffffffff ffffffff ffffffff  
3ffffe00:  ffffffff ffffffff ffffffff ffffffff  
3ffffe10:  ffffffff ffffffff ffffffff ffffffff  
3ffffe20:  ffffffff ffffffff ffffffff ffffffff  
3ffffe30:  ffffffff ffffffff ffffffff ffffffff  
3ffffe40:  ffffffff ffffffff ffffffff ffffffff  
3ffffe50:  ffffffff ffffffff ffffffff ffffffff  
3ffffe60:  ffffffff ffffffff ffffffff ffffffff  
3ffffe70:  ffffffff ffffffff ffffffff ffffffff  
3ffffe80:  ffffffff ffffffff ffffffff ffffffff  
3ffffe90:  ffffffff ffffffff ffffffff ffffffff  
3ffffea0:  ffffffff ffffffff ffffffff ffffffff  
3ffffeb0:  ffffffff ffffffff ffffffff ffffffff  
3ffffec0:  ffffffff ffffffff ffffffff ffffffff  
3ffffed0:  ffffffff ffffffff ffffffff ffffffff  
3ffffee0:  ffffffff ffffffff ffffffff ffffffff  
3ffffef0:  ffffffff ffffffff ffffffff ffffffff  
3fffff00:  ffffffff ffffffff ffffffff ffffffff  
3fffff10:  ffffffff ffffffff ffffffff ffffffff  
3fffff20:  ffffffff ffffffff ffffffff ffffffff  
3fffff30:  ffffffff ffffffff ffffffff ffffffff  
3fffff40:  ffffffff ffffffff ffffffff ffffffff  
3fffff50:  ffffffff ffffffff ffffffff ffffffff  
3fffff60:  ffffffff ffffffff ffffffff ffffffff  
3fffff70:  ffffffff ffffffff ffffffff ffffffff  
3fffff80:  ffffffff ffffffff ffffffff ffffffff  
3fffff90:  ffffffff ffffffff 6e6f6370 63745f6e  
3fffffa0:  400002e9 6574656c ffffff01 ffffffff  
<<<stack<<<

Does that make any sense? I have not tried to upload the newly created bin file (made with -O2) to my Oak from another OS platform to see if it makes any difference - might try that later :-)

[digistump]

@ajpowell @nkildal - thank you both for testing this! @nkildal - if you don't mind, can you try compiling and uploading the same sketch on another platform? to confirm that your Oak is otherwise working?

[nkildal]

@Erik: Yes - I'll try on Windows 10 in a minute. Just to make sure I'm using the correct esptool.py syntax - this is what I'm doing to flash the Oak:

./esptool.py --baud 115200 --port /dev/tty.SLAB_USBtoUART write_flash -fs 32m 0x1000 ./blank.bin 0x101000 ./blank.bin 0x2000 <mybinfile>

Is this still correct?

[digistump]

@nkildal yep that is correct - the blanks clear any bootloader setting so it boots to rom 0 in all cases, and the bin is written to the rom 0 slot

thanks!

[nkildal]

Hmm - I think esptool.py is behaving weird - clearly only part of the bin file is flashed:

C:\Users\nki\esptool>esptool.py --port COM3 --baud 115200 write_flash -fs 32m 0x1000 blank.bin 0x101000 blank.bin 0x2000 oakblink.ino.bin
Connecting...
Erasing flash...
Took 0.13s to erase flash block
Wrote 4096 bytes at 0x00001000 in 0.4 seconds (84.2 kbit/s)...
Erasing flash...
Took 0.08s to erase flash block
Wrote 4096 bytes at 0x00101000 in 0.4 seconds (84.7 kbit/s)...
Erasing flash...
Took 0.12s to erase flash block
Wrote 2048 bytes at 0x00002000 in 0.2 seconds (82.3 kbit/s)...

Leaving...

C:\Users\nki\esptool>dir *.bin
22-06-2015  16:27             4.096 blank.bin
27-01-2016  22:33           255.008 oakblink.ino.bin

[erik]

@nkildal you probably want to ping @digistump, not @erik

:smile:

[ajpowell]

Agree that OS X El Capitan 10.11 is acting strangely, though not able to find anything specific on the web...

Anyway, what I am seeing is:

OS X El Capitan 10.11.3 - just upgraded from .2 to .3 as I saw it was available - thought it might help...but not for this problem :(

Adrians-MBP:Development apowell$ ./esptool.py --baud 115200 --port /dev/tty.usbmodem14131 write_flash -fs 32m 0x1000 blank.bin 0x101000 blank.bin 0x2000 oak_blink.ino.bin
Connecting...

A fatal error occurred: Failed to connect to ESP8266

OS X Yosemite 10.10.5 - moving the USB connection over to machine running Yosemite, it immediately worked:

Adrians-Mac-Pro:Oak apowell$ ./esptool.py --baud 115200 --port /dev/tty.usbmodem3d21 write_flash -fs 32m 0x1000 blank.bin 0x101000 blank.bin 0x2000 oak_blink.ino.bin
Connecting...
Erasing flash...
Wrote 4096 bytes at 0x00001000 in 0.4 seconds (84.3 kbit/s)...
Erasing flash...
Wrote 4096 bytes at 0x00101000 in 0.4 seconds (83.4 kbit/s)...
Erasing flash...
Wrote 260096 bytes at 0x00002000 in 25.3 seconds (82.3 kbit/s)...

Leaving...

@nkildal - Clearly you are getting a little bit further than me on v10.11 - what is the final revision number on the system you are using?

[nkildal]

Ah - sorry erik :-)

@ajpowell: I am running 10.11.3 - your topmost esptool error looks like it may be a communication problem?

@digistump: I finally got some progress flashing an OSX generated bin file from Windows 10.

I compiled the blink sketch on OSX El Capitan 10.11.3 and then transferred the bin file to a Windows 10 machine, where I then flashed my Oak. I tried various combinations of c, c.elf and cpp compiler -O flags in platform.conf - all except one combination failed to create a working bin file: I only ended up with a working bin file, when all 3 flags were set to -O2 :-)

So: compiling on OSX 10.11.3 with all 3 flags changed from -Os to -O2 and then transferring and flashing the bin file on Windows seemed to work for me.

Perhaps the above information is useful - I'm a bit confused :-)

[DarkLotus]

Morning all!

@ajpowell Are you sure you have a stable connection? I know to begin with i had some dodgy soldering on one of my ground pins and getting into serial flash mode was hit and miss.

@nkildal Glad to hear it worked for you, Looks like we can confirm -O2 as working on all platforms then, for the blink example anyway.

Interesting that just -O2 on cpp works for linux, but osx needs all three, we must be hiding a deeper issue lol.

[digistump]

Github is back!

@nkildal - Did you completely exit and restart Arduino IDE between changes to the -O flags? Just a recompile won't force it to refresh the platforms.txt data.

Building a new beta firmware with -O2 on all three for now - but I agree @DarkLotus , something bigger seems to be going on here.

[digistump]

Instruction for restoring Oak to factory: http://github.com/digistump/OakRestore

[nkildal]

@digistump - hmm no I did not restart the IDE between the changes - I do however see different file sizes for the bin files.

Well - I also feel something bigger is going on, so I'll stop fooling around and instead try to use your factory restore instructions on my 2 of my 3 Oaks tonight, making sure the serial adapter and power conditions are optimal..

[ajpowell]

@DarkLotus - loose connection could be the problem - currently have the Oak connected via some headers in a breadboard - I'll try soldering those tonight when I get home - however, when I transferred my usb connector between systems, I'm pretty sure the breadboard didn't get moved - I'll let you know how I get on.

[digistump]

@nkildal - interesting, I guess I'm wrong about it - it must only be boards.txt that requires a restart to update, often deciphering how the Arduino IDE does things takes a bit of magic! (or reading java sources)

Thanks - let me know how the factory restore goes!

[digistump]

New beta test release: https://github.com/digistump/OakCore/releases/tag/0.9.2

@DarkLotus @ajpowell @nkildal @ripred

[ajpowell]

@digistump - Thanks - Will try this tonight when I get home.

[DarkLotus]

Past midnight here so i cant test any further tonight but testing with a fresh oak. Run SoftAP, Oak reboots, appears to grab firmware (15 secs of fast flashing), never connects to particle though. Re ran setup a few times without any change in behaviour. Will get some Serial logs in the morning.

[cpetito]

@digistump - I updated the Arduino IDE to 0.9.2 and now get the following error while trying to compile the simple blink sketch:

Arduino: 1.6.7 (Windows Vista), Board: "Oak by Digistump, 80 MHz, Particle OTA, OAK (4M/1M SPIFFS), Single - 1MB (Fullsize)" --- snip --- Board oak (platform oak, package digistump) is unknown Error compiling.

Any thoughts as to how to investigate/correct this issue?

BTW, the previous version worked fine. In fact I was able to compile the web server example and load it via the serial link with no issues.

Thanks!

[nkildal]

@digistump - Good news!

2 previously bricked Oaks successfully restored to fresh working order, using the method described in http://github.com/digistump/OakRestore

Everything done from my Mac, running El Capitan 10.11.3. Oaks power supplied using 2A wall wart - programmed using serial TTL adapter with GNS/TX/RX connected to Oaks.

Next step: programming using Arduino IDE :-)

[nkildal]

Did the following (all steps on Mac OS X El Capitan 10.11.3):

1. shut down the Arduino IDE
2. deleted the ~/Library/Arduino15 directory
3. started the Arduino IDE
4. added "http://digistump.com/package_digistump_index.json" as additional board manager url in preferences
5. tried to the Digistump Oak board in the boards manager

It failed showing this error message:

 Invalid archive: it must contain a single root folder while file __MACOSX/ is outside 0.9.1/
java.lang.RuntimeException: java.io.IOException: Invalid archive: it must contain a single root folder while file __MACOSX/ is outside 0.9.1/

Had a look inside the ~/Library/Arduino15/stagingpackages/oakcli-0.9.1-osx.zip file:

MacBook-Pro-2:packages nicolai$ unzip -l oakcli-0.9.1-osx.zip 
Archive:  oakcli-0.9.1-osx.zip
  Length     Date   Time    Name
 --------    ----   ----    ----
        0  01-26-16 11:26   0.9.1/
 19526676  01-24-16 04:52   0.9.1/oak
        0  01-26-16 11:26   __MACOSX/
        0  01-26-16 11:26   __MACOSX/0.9.1/
      222  01-24-16 04:52   __MACOSX/0.9.1/._oak
 --------                   -------
 19526898                   5 files

I then replaced the oakcli-0.9.1-osx.zip file, with a new file, where the __MACOSX directory was removed. Restarted the Arduino IDE, went into the Boards Manager and added the board again - this time with success :-)

[nkildal]

I seem to be unable to flash my Oaks via the Particle cloud. Configuring the "oak" binary - entering my user/pass and selecting the destination Oak - woks fine. The upload and flash start seems to also work, but nothing happens on my Oaks:

Sketch uses 259,370 bytes (24%) of program storage space. Maximum is 1,040,368 bytes.
Global variables use 51,064 bytes (62%) of dynamic memory, leaving 30,856 bytes for local variables. Maximum is 81,920 bytes.
/Users/nicolai/Library/Arduino15/packages/digistump/tools/oakcli/0.9.1/oak /var/folders/wg/s_dd80c14z7dlyzgzh96mn640000gp/T/build9be48dc9aa0fd82acc80b50bcacd7309.tmp/DigistumpOak_HelloWorld.ino.bin 
Sending file to cloud, to flash to device.
Device flashing started successfully.

Is the cloud functionality disabled, while we debug?

[digistump]

@nkildal - thanks for the tip on the oakcli - I will get that fixed

The ones you are trying to do the OTA with - did you go back through the initial setup process to download the update with them? You will need to do that before they can be flash over OTA - to do so just plug them in and do "I'm just configuring the wifi" but watch the LED, if it only blinks fast for a few seconds you'll need to retry until it blinks for at least 20-40 seconds. (and to answer your question - no, cloud functionality should be working and I tested it before releasing with some fresh oaks)

[digistump]

@cpetito - looking into it now, its working on windows for me, but trying a fresh install - will follow up on it here #19

[nkildal]

Well - actually my Oaks did not seem to want to register on the cloud, so: I did another factory restore of one Oak, then went to http://build.particle.io and removed both oaks. Followed the procedure at http://rawgit.com/digistump/OakSoftAP/master/config.html, registering a new device. Firmware seemed to download (rapid blinks for minute or so), but the Oak never show up in the Particle cloud and the SoftAP never verified it. Boot messages on serial (74880 baud) says:

 ets Jan  8 2013,rst cause:2, boot mode:(3,7)

load 0x40100000, len 3632, room 16 
tail 0
chksum 0xc0
load 0x3ffe8000, len 352, room 8 
tail 8
chksum 0x82
csum 0x82

OakBoot v1 - N,BP,8

I can see that my Oak connects to my wifi and grabs an IP address... Anything else I can try?

[digistump]

That sounds like the perfect procedure and your serial log is as expected - it is booting to the updated firmware at location 8

what do you get at 192.168.0.1/particle - when connected to the Oak AP of course

[nkildal]

Hmm - I can't seem to make it boot into AP mode - connecting pin 10 to GND and applying power gives this output on the serial console at 74880 baud:

 ets Jan  8 2013,rst cause:2, boot mode:(3,7)

load 0x40100000, len 3632, room 16 
tail 0
chksum 0xc0
load 0x3ffe8000, len 352, room 8 
tail 8
chksum 0x82
csum 0x82

OakBoot v1 - N,BP,8

I can see it connects to my wifi and grabs an IP address - just like when booting normally (without pin 10 grounded). Browsing to this ip on /particle gives me nothing - seems like no web server is running:

MacBook-Pro-2:OakRestore-master nicolai$ ping 10.0.0.196
PING 10.0.0.196 (10.0.0.196): 56 data bytes
64 bytes from 10.0.0.196: icmp_seq=0 ttl=255 time=1.912 ms
64 bytes from 10.0.0.196: icmp_seq=1 ttl=255 time=4.561 ms
64 bytes from 10.0.0.196: icmp_seq=2 ttl=255 time=1.490 ms
^C
--- 10.0.0.196 ping statistics ---
3 packets transmitted, 3 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 1.490/2.654/4.561/1.359 ms
MacBook-Pro-2:OakRestore-master nicolai$ telnet  10.0.0.196 80
Trying 10.0.0.196...
telnet: connect to address 10.0.0.196: Connection refused
telnet: Unable to connect to remote host

[nkildal]

Just did a factory restore on my other Oak - connected to the Oak AP. Now http://192.168.0.1/particle gives me:

File Not Found

[ajpowell]

@digistump - I updated the Arduino IDE ion a similar way to @nkildal, but didn't get an error - checking /staging/packages, I see that oakcli-0.9.1.zip only contains 0.9.1/oak...so I guess you have already updated that - great! Should that not be 0.9.2? Though Boards Manager does show that 0.9.2 is deployed...

Needed to check I'd got the correct Oak selected, so went to the deployed copy of oak, but find that it is not executable i.e.

Adrians-MBP:0.9.1 apowell$ pwd
/Users/apowell/Library/Arduino15/packages/digistump/tools/oakcli/0.9.1
Adrians-MBP:0.9.1 apowell$ ls -lrt
total 38144
-rw-r--r--  1 apowell  staff  19526676 24 Jan 03:52 oak

A simple chmod 755 oak, fixes this, of course. Need to do the same for esptool2 as well:

Adrians-MBP:0.9.1 apowell$ pwd
/Users/apowell/Library/Arduino15/packages/digistump/tools/esptool2/0.9.1
Adrians-MBP:0.9.1 apowell$ ls -lrt
total 40
-rw-r--r--  1 apowell  staff  18112 18 Jan 18:39 esptool2

This occurred on both Yosemite and El Capitan.

Reset Oak successfully using OakRestore - had to do chmod 755 on esptool.py (ah...except just realised why you put 'python esptool.py ...' now - doh!)

Connected to the Oak AP - 192.168.0.1/info gives sensible data; 192.168.0.1/particle gives File Not Found.

I have just been trying to get this Oak connected to Particle - had to try a couple of times then got it - no shows as active on the Particle dashboard -I didn't delete from the Particle dashboard before hand (can't see how to, to be honest!)

Built and complied the code given above in the Arduino IDE and deployed OTA from my Yosemite machine - and SUCCESS! My Oak is now flashing 4s on, 1s off.

So, in summary:

• OakRestore works OK to reset to factory conditions (albeit keeping the Particle data)
• Building on Mac OSX appears to be working correctly (couple of minor issues around permissions on binaries)
• Deploying OTA is also working - deployment is a little slow, took a couple of minutes in my case but this was mentioned in an earlier post somewhere - improvements should been seen once beta tests are complete.

And on that note, I'm calling it a night ;)

[nkildal]

@digistump - I'd just like to add to @ajpowell: After having gone through several OakRestore experiments - finally getting all my Oaks registered on Particle - I have also been experimenting with OTA deployment. Everything seems to work just fine. I tested both the classic Oak blink sketch - but also tested a sketch using "Blynk" to control the pins of the Oak - success!

Also done for tonight :smile:

[DarkLotus]

Just wanted to report all working on my end as well since trying it this morning.

Fresh Oak, Updated, Clouded, then OTA flashed. All smooth as silk :)

[haakonnessjoen]

All working here too. But I still had to chmod +x the tool-binaries in Arduino. (I'm running OS X Yosemite)

Also, I could not save the oakcli-settings with the binary downloaded from the link in the wiki. I had to use the binary that came with the latest arduino-oak-board files. After using that one, it saved the config to the correct file, and OTA worked fine.

Although the wiki said the firmware update would take several minutes, it only took about 10-20 seconds I think. But OTA takes more than a minute as foretold.

It's working great, I have tested both Particle.publish and Particle.variable, and they function as they should :)

[digistump]

Fixing the executable permissions now, by switching to using tar.gz for OSX packages

I've updated the wiki links to point to the right oakcli

Glad it is working for most(?) who try it now! Thanks for testing!

[ajpowell]

Been playing around some code and created a few simple code examples earlier today - plan to create more as I explore the oak device and particle - putting the code here for now https://github.com/ajpowell/OakSamples - these could be added to the Wiki later on.

Did find an issue when trying to compile the OneWire library - raised an issue for this: https://github.com/digistump/OakCore/issues/22

To retest the deployment on OSX, I have just cleared down the ~/Library/Arduino15 directory and re-deployed as per tutorial - basic blink code has just deployed OTA with no permission issues (oak and esptool2) that had been seen previously - deployment on OSX is now working well.

[DarkLotus]

Have not had as much free time the past few days but I've still been digging!

I've narrowed it down thus far to something in the Oak/Particle integration. Stripping the oak includes and Particle.connect/ Particle.process from arduino.h and esp_main.cpp results in -0s working. Hopefully will have more free time over the weekend to narrow it down further.