I was about to post the below info / link and came across your post, which is quite relevant! Sorry for not responding earlier though, must have missed it as it poped up around exam time...
When doing some work with an ESP8266 module earlier today, I came across a handy page documenting recommended minimum support hardware - and more importantly, what the different error codes from the bootloader mean. The following information is sourced
from that ESP8266 Arduino documentation.
At startup the ESP8266 (which is the CPU in the Oak) bootloader prints out the current boot mode over the serial port. For example: rst cause:2, boot mode:(3,6)
rst cause| Number | Description |
| 0 | unknown |
| 1 | normal boot |
| 2 | reset pin |
| 3 | software reset |
| 4 | watchdog reset |
boot modethe first value reflects the pin setup of the GPIO pins (0, 2 and 15).
| Number | GPIO15 | GPIO0 | GPIO2 | Mode |
| 0 | 0V | 0V | 0V | Not valid |
| 1 | 0V | 0V | 3.3V | Uart |
| 2 | 0V | 3.3V | 0V | Not valid |
| 3 | 0V | 3.3V | 3.3V | Flash |
| 4 | 3.3V | 0V | 0V | SDIO |
| 5 | 3.3V | 0V | 3.3V | SDIO |
| 6 | 3.3V | 3.3V | 0V | SDIO |
| 7 | 3.3V | 3.3V | 3.3V | SDIO |
Since you got a rst cause of 2, that means the oak/esp8266 was reset manually. That's fine. The boot mode, however, is 3, which is flash mode. So if you got that message when trying to run esptool, that suggests that GPIO2 (
which is mapped to P2) was not pulled to ground properly, as when doing the esptool update, the oak/esp8266 should be in uart mode. However, at the same time, there is the oakboot message at the end, which is what you should see if the oak is booting normally (in boot mode 3).
However, having said all that... the usual culprit if soft-ap not finding the Oak is just that it is being pedantic. Try connecting to the oak on another device if you can. Sometimes a phone or tablet seems to have more luck than a desktop computer. Hopefully you have had some luck finding out the problem or fixing it in the mean time!
