Holding pin 0 low at boot does not enter config mode

[kh90909]

The current sketch doesn't run either. I turned on DEBUG_SETUP in particle_globals.h to look at the serial output and found that it just spews random accented characters after booting. In contrast, when booted with pin 0 unconnected, after flashing the system image with DEBUG_SETUP turned on, the expected debug messages appear on the serial port.

This happens both when the Oak has been programmed with user code and just after flashing the system image, which makes me think this is happening very early in the boot process. If the Oak boots the system image, it should ignore pin 0 according to check_safe_mode() in particle_core.cpp.

I have confirmed that pin 0 is being read correctly with a simple sketch that reads its value and writes it to the LED pin. I've also made sure that I have the latest versions of all the Oak repos and have built and flashed the latest firmware to the Oak.

Anyone else having this issue, or is it specific to my Oak?

[DarkLotus]

Spewing out garbage sounds like the wrong baud rate, Bootloader uses 74880
then afterwards it's normally 115200. have you tried at both these speeds?
The garbage may have been the Bootloader stuck in a boot loop.

On Tue, Feb 16, 2016 at 3:59 PM, kh90909 notifications@github.com wrote:

The current sketch doesn't run either. I turned on DEBUG_SETUP in
particle_globals.h
https://github.com/digistump/OakCore/blob/918046ba7160bed34ae51177eb610507181ee1d9/cores/oak/OakParticle/particle_globals.h
to look at the serial output and found that it just spews random accented
characters after booting. In contrast, when booted with pin 0 unconnected,
after flashing the system image with DEBUG_SETUP turned on, the expected
debug messages appear on the serial port.

This happens both when the Oak has been programmed with user code and just
after flashing the system image, which makes me think this is happening
very early in the boot process. If the Oak boots the system image, it
should ignore pin 0 according to check_safe_mode() in particle_core.cpp

OakCore/cores/oak/OakParticle/particle_core.cpp

Line 3848 in 918046b

void check_safe_mode(void){

.

I have confirmed that pin 0 is being read correctly with a simple sketch
that reads its value and writes it to the LED pin. I've also made sure that
I have the latest versions of all the Oak repos and have built and flashed
the latest firmware to the Oak.

Anyone else having this issue, or is it specific to my Oak?

—
Reply to this email directly or view it on GitHub
#45.

[pfeerick]

Same here. I got my Oaks yesterday, installed the latest 0.9.3 Arduino IDE, and got two Oaks to update and work (eventually, another issue documents my saga with those). I could not get either one to enter config mode by shorting Pin 0 to GND - I had to turn off the AP and wait for it to go failsafe (yes, I know I could have uploaded a sketch with the reset to config call... but didn't want to get into the endless loop issue that someone else documented on the forum).

[kh90909]

Spewing out garbage sounds like the wrong baud rate, Bootloader uses 74880
then afterwards it's normally 115200. have you tried at both these speeds?

I had the same thought, but dismissed the idea after trying all the common baud rates. Didn't know the bootloader used an odd one. That's got to be it, thanks!

I'll try it tonight and see what the bootloader is saying.

[kh90909]

I'll summarize first, since this is a long comment:

Pin 0 can't be used to trigger config mode as it puts the ESP8266 into undocumented boot modes that do not load code from the flash chip. We need to use a different pin.

Happy to make and test the necessary code and doc changes (should be minimal) and submit a pull request. @digistump you initially started with pin 10, then switched to pin 1, and then pin 0. Do you want to go back to pin 10 or choose a new one?

Details:

With the right baud rate, I was able to see what was going on. A fatal exception was occurring:

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

Fatal exception (0):
epc1=0x40100003, epc2=0x00000000, epc3=0x00000000, excvaddr=0x00000000, depc=0x00000000

Sometimes, I got the same message, but with epc1=0x40081dc8.

After some digging, I tracked down the issue. Pulling pin 0 low, which connects to GPIO2 on the ESP8266, selects a different boot mode.

Most of the information on the internet about ESP8266 boot modes lists just three (SPI flash, UART download, and SD card), which are selected by a combination of MTD0 (aka GPIO15), GPIO0 and GPIO2. This might give the impression that booting with an unspecified combination of these pins would default to SPI flash. In fact, there are lesser known boot modes that correspond to these other combinations of MTD0, GPIO0 and GPIO2:

MTD0 GPIO0 GPIO2 Mode
0    0     0     Remapping
0    0     1     UART boot
0    1     0     Jump boot
0    1     1     Flash boot
1    0     0     SDIO LowSpeed V2 IO
1    0     1     SDIO HighSpeed V1 IO
1    1     0     SDIO LowSpeed V1 IO
1    1     1     SDIO HighSpeed V2 IO

These are taken from 0D-ESP8266__Pin_List__Release_15-11-2014.xlsx, which is available from Espressif here. Unfortunately, they do not provide any documentation on what the "Remapping" and "Jump boot" modes do. From this comment in Russian (translation), it appears that jump boot immediately starts executing from the start of IRAM (0x40100000). This explains the fatal exception above, since nothing is loaded into IRAM at that point.

[digistump]

Yes - sorry was supposed to be pin 1 not pin 0, not sure how I missed that... the coming release will have this fixed to pin 1

Open to suggestions as to what pin this should be - but pin 10 doesn't seem to work either due to its other functions (GPIO16) as wake with a internal pull up

[kh90909]

I guess pin 1 isn't ideal because the config sketch flashes the LED, so we lose the visual feedback and the driven pin is shorted to ground.

Pins 0, 2 and 10 are out due to boot mode and wake as discussed, and it's probably best to also avoid the UART pins 3 and 4 too as it would interfere with debugging, etc. Avoiding the SPI pins 7, 8 and 9 is likely sensible also, so that leaves 5 and 6.

Looking through the shields, it looks like more of them use pin 5, so I think pin 6 is the best choice for config mode.

[digistump]

Pin 6 is used as Slave Select for most SPI devices

Maybe a menu option to choose 1,6,or none?

On Tue, Feb 23, 2016 at 5:47 PM, kh90909 notifications@github.com wrote:

I guess pin 1 isn't ideal because the config sketch flashes the LED, so we
lose the visual feedback and the driven pin is shorted to ground.

Pins 0, 2 and 10 are out due to boot mode as discussed, and it's probably
best to also avoid the UART pins (3, 4) too as it would interfere with
debugging, etc. Avoiding the SPI pins 7, 8 and 9 is likely sensible too, so
that leaves 5 and 6.

Looking through the shields, it looks like more of them use pin 5, so I
think pin 6 is the best choice for config mode.

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

[kh90909]

Sounds fine to me, as long as you make 1 or 6 the default so that someone
isn't likely to disable it unless they know what they're doing.

But it sounds like a lot of effort to add a menu...maybe just go with 1 or
6? Even if you have an SPI device using pin 6 as slave select, I don't see
a way that pulling it low could cause problems. The SPI device won't be
usable in config mode anyway, and even if the SPI slave drives MISO, the
Oak MISO pin will be an input in that mode, so nothing gets shorted.

On Wed, Feb 24, 2016 at 2:07 AM, Erik Tylek Kettenburg <
notifications@github.com> wrote:

Pin 6 is used as Slave Select for most SPI devices

Maybe a menu option to choose 1,6,or none?

On Tue, Feb 23, 2016 at 5:47 PM, kh90909 notifications@github.com wrote:

I guess pin 1 isn't ideal because the config sketch flashes the LED, so
we
lose the visual feedback and the driven pin is shorted to ground.

Pins 0, 2 and 10 are out due to boot mode as discussed, and it's probably
best to also avoid the UART pins (3, 4) too as it would interfere with
debugging, etc. Avoiding the SPI pins 7, 8 and 9 is likely sensible too,
so
that leaves 5 and 6.

Looking through the shields, it looks like more of them use pin 5, so I
think pin 6 is the best choice for config mode.

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

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

[digistump]

Not too much effort so I added all three - but I did make 6 the default
since as long as you don't have a shield attached it is easiest to use with
no side effects.

On Wed, Feb 24, 2016 at 10:27 AM, kh90909 notifications@github.com wrote:

Sounds fine to me, as long as you make 1 or 6 the default so that someone
isn't likely to disable it unless they know what they're doing.

But it sounds like a lot of effort to add a menu...maybe just go with 1 or
6? Even if you have an SPI device using pin 6 as slave select, I don't see
a way that pulling it low could cause problems. The SPI device won't be
usable in config mode anyway, and even if the SPI slave drives MISO, the
Oak MISO pin will be an input in that mode, so nothing gets shorted.

On Wed, Feb 24, 2016 at 2:07 AM, Erik Tylek Kettenburg <
notifications@github.com> wrote:

Pin 6 is used as Slave Select for most SPI devices

Maybe a menu option to choose 1,6,or none?

On Tue, Feb 23, 2016 at 5:47 PM, kh90909 notifications@github.com
wrote:

I guess pin 1 isn't ideal because the config sketch flashes the LED, so
we
lose the visual feedback and the driven pin is shorted to ground.

Pins 0, 2 and 10 are out due to boot mode as discussed, and it's
probably
best to also avoid the UART pins (3, 4) too as it would interfere with
debugging, etc. Avoiding the SPI pins 7, 8 and 9 is likely sensible
too,
so
that leaves 5 and 6.

Looking through the shields, it looks like more of them use pin 5, so I
think pin 6 is the best choice for config mode.

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

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

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

[kh90909]

Great. Thanks for all your effort Erik.