Fatal Exception 28 #16
Comments
|
Okay i read the oakboot source. Grounding pin 10 it boots with N,BU,0 instead of N,BP,0 which i hadnt noticed before. But then it spams Fatal 28 the same as above since its loading the same rom i guess. |
|
Anyone getting a Fatal Exception error after successfully connecting to Particle and trying to upload a sketch, if you can please do the following, the more people who can do this the better I can diagnose the issue (as I haven't been able to reproduce yet):
File for dumping flash: |
|
Also if anyone seeing this error wants to try this - unzip the file attached to this and put it in the same folder as esptool.py from the post above this. Follow 1-3 above then run the command "esptool.py --baud 115200 --port COMX write_flash -fs 32m 0x3fc000 blank.bin 0x3fd000 blank.bin 0x3fe000 blank.bin 0x3ff000 blank.bin" Please do a flash dump per above first, then try that, and let me know if your unit can then boot - again serial log is best. |
|
Hi Erik My Oak is spamming with Fatal 28 exceptions when I power it up (also with pin 10 grounded) MacBook-Pro-2:Oak_debug nicolai$ ./esptool.py --baud 115200 --port /dev/tty.SLAB_USBtoUART read_flash 0x000000 0x300000 flash_dump.bin I also tried grounding pin10 before applying power to the board, but with the same result. Do I need to something else to get the flash image dumped? /Nicolai |
|
@nkildal Sorry - I missed an important part in my instructions - please connect Pin 2 to GND and then power up and dump the flash - same for writing files to flash - this puts the device in the serial bootloader mode - you'll need to power cycle it after a write or dump to put it back in the serial bootloader mode again. |
|
No problem - it worked! Removed for security reasons. |
|
Thanks @nkildal - if you don't mind trying the possible fix (it's a bit of a shot in the dark, but won't disable the Oak any further) - I'd love to hear if it works for you, I'll take a deep look at the dump file later today or first thing tomorrow, but at a glance nothing obvious yet. |
|
I tried writing the blank.bin file: Powering down and up again, gives me repeating fatal (28) exceptions on serial... |
|
Looks like the final one failed @nkildal - can you try just this: esptool.py --baud 115200 --port COMX write_flash -fs 32m 0x3ff000 blank.bin |
|
Here goes: |
|
And a little more background - what we're trying here is blanking out where the Oak stores wifi config data - not the SSID and passcode which is saved in the particle config area and CRCed on save, but the data it uses to reconnect quickly to a known good network - it is the one area I have no control over as it is written inside the ESP8266 SDK, which is why I suspect it might be at fault. |
|
blank2.zip esptool.py --baud 115200 --port COMX write_flash -fs 32m 0x3fe000 blank2.bin If that doesn't work I'll hold off on any more hunches until I successfully reproduce the issue so I can test locally. If that doesn't work - if you don't mind doing a full dump (the one before was only the most important 3/4) so that maybe if I load your full rom into one of mine I can reproduce the issue: esptool.py --baud 115200 --port COMX read_flash 0x000000 0x400000 flash_dump_full.bin Probably best to email the result as I realized that it could present some security issues, it is possible to deconstruct the file and get someones WiFi password - of course don't send it, if you are not comfortable sending that to me (I won't use it nor even care to look at it, but I want to be clear as to what is being sent). I removed the one you uploaded earlier for the same reason. Thanks for all your help. |
|
Ok - tried blank2.bin: Disconnecting power, removing GND on pin2 and powering up again, still gives me a steady green light - serial console still shows scrolling fatal exception 28 :-( I'll go ahead and produce a full dump, and send it to you in an email - I have no issues sending you the data - just happy to help out :-) |
|
Awesome @nkildal - thanks again - next chance I get I will try loading it into an oak and see if I can reproduce |
|
Here is a dump of mine as well, wifi passwords are for suckers, so nothing personal in here. My AP it "should" be connected to is called "KKLOLK" I noticed at offset 0x100B1D and 0x200B1D there is a string "KKLOLK.743c" which seems strange? Could i dump one of my working oaks and flash it? or would that give me a world of pain and conflicting device id's lol Bit off topic but, if i power my oak from dedicated wall psu, rather than my USB hub I would then need a ground line for serial yes? I assume im getting away with tx/rx only since my stlink and the oak are powered via same USB hub currently? If that's the case just a jumper between grnd on the oak and grnd on the st link would be all thats needed? Using an ST-Link v2 from the top of a STM nucleo development board. |
|
Awesome - thanks! @DarkLotus I wouldn't advise moving a dump from one to the other - you could dump a good one from 0x0 to 0x201000 and then replace the device ID's with the ones from this dump - you'll find them just past 0x100000 and 0x200000 but ymmv |
|
think ill wait, i dumped a good firmware and there is quite a few differences apart from the user rom sections. |
|
@DarkLotus Would you mind compiling and uploading the bin file produced by the same Blink example you flashed with Arduino IDE - hit "Verify" instead of "Compile" and then grab the path to the bin file from the output at the bottom of the window. (You may need to turn on Verbose compiling in the preferences). I've got a way to fix the bricked units, and some ways to avoid this from bricking units, but still no idea why this occurred unless the compiled bin file was actually bad to start with. |
|
sketch_jan22a.cpp.zip |
|
Comparing my bad bin to the sketch bin, its byte for byte there. so my compiled sketch must be bad? |
|
@DarkLotus yes that's exactly what I'm thinking - what OS was this compiled on? Mind also uping the exact sketch and the .elf file from the same folder as the bin? - I'll compile the sketch and compare, and the elf can be used to disassemble and see where the error occurs |
|
@nkildal - What OS were you using? Any chance you can upload the sketch, bin and elf as requested of @DarkLotus above? Thank you both for helping unravel this mystery! |
|
@erik: I'd love to, but it has to wait until I get home from work in about 8 hours - 7:15AM here in Denmark :-) The sketch was the blink example with the two Particle.delay() lines.. |
|
@nkildal - thanks! that is actually all I need to know, there is a very definite pattern developing here - if @DarkLotus says he is on OSX and even more so if he was on El Cap - then 100% of people who have written to me with this issue are on El Cap |
|
Compiled on Linux x64, Ardunio 1.6.5 sketch_jan22a.elf.zip // the loop routine runs over and over again forever: I can do a build on OSX 10.10 or Windows as well if needed |
|
@erik: Can confirm, once Nicolai Kildal and I found some issues with oak.js via comments on the KS comment section on OS X (me El Capitan 10.11.3) and I initiated the upload of my first sketch, it was bricked after that. My serial adapter is still somewhere in a box from my move from California so haven't been able to contribute to this thread. But yes, El Cap here. Firmware upgrade seemed to go fine, registered with particle fine, good to go. First upload via the oak.js (via Node.js and corrected code) seemed to brick it. Powered via USB on Mac Pro desktop. For what clues it might add I'm an IOS dev with probably their latest updates to gcc/LLVM &c. if that matters at all. |
|
@ripred - Thanks for the info! Here is what I've figured out this far, in case any of you are interested in the details:
To deal with #4 I've added a bunch more logic around when to consider a new rom file as good, namely instead of just booting it needs to actually run, and also some extra logic for when to jump into this mode. I've also fixed the Pin10 entry into config mode. I've booted one of my computers into OSX to address the main issue, but haven't got too far in terms of results yet - things/thoughts on my list:
Thank you all again for your help! More tomorrow! |
|
I thought I'd add a bounty on this - in case someone wants to figure it out before I get back to it tomorrow. TASK: HOW TO TEST: Manually upload the bin file created when you compile the sketch, using the following command (blank.bin is attached: esptool.py --baud 115200 --port /dev/tty/YOURPORT write_flash -fs 32m 0x1000 blank.bin 0x101000 blank.bin 0x2000 YOURSKETCH.bin Confirm that it fails with a fatal exception loop on the serial monitor with the current install. Then confirm that it succeeds (by watching via serial monitor and making sure the blinking executes) with your fix. NOTE: blank is just being used to overwrite the bootloader config (and backup copy of the bootloader config) to force it to boot into rom 0, where the bin is being written
Bootloader layout for those curious why blank is being written to those locations: Sketch for testing: |
|
Just to let you know your on the right track, i flashed the same sketch from windows. and my dead oak is back to life. You missed the blank.bin, but if anyone wants to follow the above, you want a 4kb blank.bin |
|
Ah - sorry erik :-) @ajpowell: @digistump: 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. 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 :-) |
|
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. |
|
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. |
|
Instruction for restoring Oak to factory: http://github.com/digistump/OakRestore |
|
@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.. |
|
@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. |
|
@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! |
|
New beta test release: https://github.com/digistump/OakCore/releases/tag/0.9.2 |
|
@digistump - Thanks - Will try this tonight when I get home. |
|
Past midnight here so i cant test any further tonight but testing with a fresh oak. |
|
@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)" 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! |
|
@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. Next step: programming using Arduino IDE :-) |
|
Did the following (all steps on Mac OS X El Capitan 10.11.3):
It failed showing this error message: Had a look inside the ~/Library/Arduino15/stagingpackages/oakcli-0.9.1-osx.zip file: 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 :-) |
|
I seem to be unable to flash my Oaks via the Particle cloud. Is the cloud functionality disabled, while we debug? |
|
@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) |
|
Well - actually my Oaks did not seem to want to register on the cloud, so: I can see that my Oak connects to my wifi and grabs an IP address... |
|
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 |
|
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: I can see it connects to my wifi and grabs an IP address - just like when booting normally (without pin 10 grounded). |
|
Just did a factory restore on my other Oak - connected to the Oak AP. |
|
@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. A simple chmod 755 oak, fixes this, of course. Need to do the same for esptool2 as well: 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:
And on that note, I'm calling it a night ;) |
|
@digistump - I'd just like to add to @ajpowell: Also done for tonight |
|
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 :) |
|
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 :) |
|
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! |
|
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: #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. |
|
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. |
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.
The text was updated successfully, but these errors were encountered: