GPIO15 is pulled down because it is a bootstrap pin that changes the boot mode of the ESP.

What software are you using, and are you sure this software supports the Xtensa LX106 core in the ESP8266?

As far as I understand it, that is a bug in gdb; because of some optimizations gcc does, some variables may be in registers or not available at all, and gdb doesn't know about that. You can try recompiling your code with -Og instead of -Os or whatever -Ox setting you're using now.

Seems the bit for that went undocumented in the SDK code. In the SPI_PIN register, can you try setting bit 29? This should do what you want. We will include a definition for it in the next SDK, for now you can use this one:
#define SPI_IDLE_EDGE (BIT(29))

Erm.. the WROOM2 runs on an ESP8266, which only has one CPU (namely the Xtensa LX106).

Ah, sorry, didn't spot this topic before... Yes, breakpointing flash is pretty much only possible with a hw breakpoint for now, and hw breakpoints aren't set by default because we only have one. Also, I just concluded that may also interfere with the 'next' command... hmm, I may want to change the l...

While programming for the ESP8266 is easy, with many available options provided both by Espressif and the awesome community of people centered around our chip, support for actually debugging applications has been somewhat lacking, limited mostly to inserting printf statements in critical places. In ...

There's no PWM hardware as such, but the SDK has a pretty capable software PWM implementation. Check the pwm_* functions in the SDK, they probably do what you want.

As you all may know, the specsheet for the ESP8266 describes the chip as having an I2S port, which is a port to which you can connect an I2S DAC to get sound in and out of the chip. Unfortunately, up until now no documentation or examples about this port were available. We're working on these docume...

Can I fix this using new API function: espconn_recv_hold() and espconn_recv_unhold() like this? (I am at work, can't test this until tonight) :( No, you can't: the watchdog will reset the IC if you spend too much time in a routine, regardless of what you do inside the routine. As I've mentioned on ...

problem is if you are in deep_sleep mode(CH_PD on GND or folating). RTC is ticking, but your code is not running. So 32 bit RTC will overflow in 7.5h. If timer would be 64 bit, you have more than enough time (many, many years)to check for timer overflow. with 64bit RTC I don't see any need to have ...