BOUNTY: Fix anything that can brick a device

[digistump]

PLEASE: Report bricking issues here ONLY if you can provide a sketch/example that triggers it - anyone is then free to implement a fix for the reward.

---

Skills Required: Intermediate at C/C++ and ESP8266 knowledge
Difficulty: Unknown

Challenges/Thoughts:

We still have scattered reports of people being able to brick their Oaks with the Beta firmware - we don't want that! (at least we'd like you to have to really try to brick it).

If you find a way to brick it that does not involve modifying the core files in any way (and please no crazy obscure compiler/linker exploits that no one would ever trigger on mistake) - and you provide a fix (that doesn't break the existing functionality) we'll reward at MINIMUM the bounty, possibly more depending on the difficulty of the fix. One person can submit multiple fixes for distinctly different issues for multiple rewards.

Note: Calling the WiFi functions from a sketch to disable wifi or change its settings is not something that qualifies, as we are already removing these functions.

You are welcome and encouraged to politely ask others who have bricked for more info on the forums, here, and Kickstarter if you are actively pursing these bounties. (PLEASE: Report bricking issues here ONLY if you can provide a sketch/example that triggers it - anyone is then free to implement a fix for the reward)

When submitting a pull request please provide the sketch/example of how to replicate the bricking, as well as how it bricks it, and of course the fix in the pull request code itself.

To test:

• Register an Oak with Particle cloud (if you haven't already)
• Install Python 2.7 and ensure it is in your path
• Install the latest Oak core via board manager, download this repository and copy over the files found at APP_DATA/packages/digistump/hardware/oak/XXX where APP_DATA is where your system keeps the Arduino data and XXX is the current Oak core version.
• In cores/oak/OakParticle/particle_globals.h uncomment #define OAK_SYSTEM_ROM_4F616B 82 - this tells it to compile the OakSystem sketch as a system image not a user sketch
• Grab the latest OakSystem sketch from https://github.com/digistump/OakSystem
• Test to ensure that the issue does in fact brick the unit using the latest code.
• Make changes to the core to achieve the above task.
• Connect your Oak using a 3.3v USB to Uart adapter, connect Pin2 to GND before powering on to enter Serial bootloader mode (after an upload the code with automatically run and you'll have to power cycle it to go back to bootloader mode. Disconnect Pin2 to GND to have it run the code on next power up)
• ONCE: Grab OakRestore (https://github.com/digistump/OakRestore) and run python esptool.py --baud 115200 --port YOUR_COM_PORT write_flash -fs 32m 0x1000 blank.bin 0x2000 oaksetup_restore.bin 0x0081000 oakupdate_restore.bin 0x101000 blank.bin 0x102000 blank.bin 0x202000 blank.bin replacing YOUR_COM_PORT with your com port, to restore the Oak to factory setup so that the Serial upload will work and the Oak will boot to it.
• Use "Upload Using" "Serial" in the Arduino tools menu.
• Upload from the IDE and test, upload sketch that could previously brick it via the OTA and provide sketch and bin file as attachments so we can test. (remember to comment the OAK_SYSTEM_ROM_4F616B line back out before compiling a user sketch)

Bounty

$50 cash or $100 credit or 10 Oaks (more at our discretion if the fix turns out to fix many types of issues) - per unique fix, multiple awards (even to the same person) allowed.

If you are sure you can do this, and able to do this quickly - please feel free to respond to this issue and say that you are working on it and when you will complete it, so that others don't waste their time on it. If you are just entertaining the idea/unsure if you can do it, please don't "claim" it until you are sure.

Cash or credit is your choice. Cash to be paid via Paypal. Credit has no expiration but can only be applied to a single order and does not cover shipping (because that is how our shopping cart works, not because we want to be limiting). Oaks reward includes shipping.

You may credit yourself in the files as well, leaving in tact existing licenses and credits.

Legal Stuff: We will choose a winner at our sole discretion. The winner will be the first pull request that submits fully working code meeting the above requirements and following good coding practices, based on the timestamp of the pull request. Bounty will be awarded (or in the case of Oaks, sent) within 48 hours of confirming winner. Cash awards will be made in USD. This is not an offer for hire. All work submitted becomes the property of Digistump LLC to be used at our discretion in compliance with any associated licenses. Void where prohibited by law.

[kh90909]

While trying to reproduce the hidden network bug, I believe I've found a sketch that will brick an Oak, but I'm not sure if this counts as calling one of the "WiFi functions" that @digistump mentioned above will be removed in future.

void setup() {                
}

void loop() {
  Oak.rebootToConfig();
}

After rebooting to config mode and finishing the Soft AP configuration, the sketch runs again immediately, so it goes right back to config mode. Is this a correct assessment, or am I missing something?

Is there a legitimate reason to be able to call Oak.rebootToConfig() from a user sketch? If so, then I see two possible solutions:

1. Don't run the user sketch after configuration, but go to an empty loop instead that just waits to be programmed. The user sketch would resume after power cycling.
2. Erase the current sketch during configuration, so that it can't get stuck in a loop like this.

[DarkLotus]

#1 sounds like the better idea, Still gives user roms the ability to reboot
to config if you do change AP's or something.

Atleast for now, just dont call it directly from loop, only call it on some
certain input, ie Pin LOW, or some serial input etc.

On Sun, Feb 14, 2016 at 3:33 PM, kh90909 [email protected] wrote:

While trying to reproduce the hidden network bug, I believe I've found a
sketch that will brick an Oak, but I'm not sure if this counts as calling
one of the "WiFi functions" that @digistump https://github.com/digistump
mentioned above will be removed in future.

void setup() {
}

void loop() {
Oak.rebootToConfig();
}

After rebooting to config mode and finishing the Soft AP configuration,
the sketch runs again immediately, so it goes right back to config mode. Is
this a correct assessment, or am I missing something?

Is there a legitimate reason to be able to call Oak.rebootToConfig() from
a user sketch? If so, then I see two possible solutions:

1. Don't run the user sketch after configuration, but go to an empty
   loop instead that just waits to be programmed. The user sketch would resume
   after power cycling.
2. Erase the current sketch during configuration, so that it can't get
   stuck in a loop like this.

—
Reply to this email directly or view it on GitHub
#33 (comment).

[digistump]

This is the expected behavior because this can be used to change wifi and get a new sketch or just to change wifi and then jump back to the old sketch (think of a button attached to the Oak triggering the rebootToConfig to allow the user to change the wifi settings).

I've simplified this in the coming release though - when you boot to config it will start the config server and also if it can connect, then it will connect to Particle and can get an OTA update if one is sent. This means with a sketch like above once you change the wifi config it would reboot and end up back in config mode and able to receive a new sketch via OTA

[kh90909]

Great, this change will achieve the same essentially thing as option 1 discussed above.

[jwhendy]

I can't fix it, but I thought I'd report something that might have bricked my oak :( While you make it clear that ESP8266 libraries aren't tested, I just loaded up the Examples > ESP8266Wifi > WifiWebServer example and tried to program it over serial as described here.

Just hung at Flashing ....... forever. I bit the bullet and unplugged it. No behavior, so I figured I'd factory restore. I've done this successfully 3 times already, but this time despite the flash appearing to go OK, it gives me no blinking LED, and is not showing up as an AP. Here was the output of the restore script:

Connecting...
Erasing flash...
Wrote 4096 bytes at 0x00001000 in 0.4 seconds (86.9 kbit/s)...
Erasing flash...
Wrote 271360 bytes at 0x00002000 in 26.2 seconds (82.9 kbit/s)...
Erasing flash...
Wrote 259072 bytes at 0x00081000 in 25.0 seconds (82.9 kbit/s)...
Erasing flash...
Wrote 4096 bytes at 0x00101000 in 0.4 seconds (87.0 kbit/s)...
Erasing flash...
Wrote 4096 bytes at 0x00102000 in 0.4 seconds (87.0 kbit/s)...
Erasing flash...
Wrote 4096 bytes at 0x00202000 in 0.4 seconds (87.0 kbit/s)...

Leaving...

Is there some bit of memory that the ESP8266 sketch could have futzed with which isn't overwritten by the restore script?