I updated to the latest openocd-esp32 and recompiled, and it still doesn't halt (perhaps as you say) but I'm still getting that original error in Eclipse regarding "Cannot access memory at address 0x0". The OpenOCD output looks pretty much the same too, and reports that the gdb connection was droppe...

I saw this error just now with a v2.1.1 project however I found that reseting my USB interface and restarting Eclipse cleared it. So I have confirmed (again) that I can debug with v2.1.1. Interestingly, I note with my v2.1.1 project that the system halts at this part of the boot process: I (930) cpu...

I've been using v2.1.1 with my prijects for some time, but I ran into a show-stopping problem with I2C, so I moved my project to v3.0rc1 instead. This seems to have fixed the I2C problem but unfortunately I've now run into some stability problems that I didn't see with v2.1.1. The most serious one i...

You're probably right. I'm doing some testing with very short cables to see if I can correctly correlate cable length to glitch incidence. EDIT: yes, cable length does affect it. A very short cable shows no errors over a 12 hour test. BTW, when I enable WiFi with master ESP-IDF, I'm sometimes gettin...

Interesting read. What's the status of this investigation in terms of ESP-IDF as of January 2018? Is there still a latent issue in the master branch of ESP-IDF? I ask because I've been having a lot of trouble with glitchy I2C for the last week, and although moving to the master branch (from 2.1.1) s...

For production purposes it is recommended to use latest stable version available. At the moment, it is 2.1.1. If you are at an early stage in the development process, it might be reasonable to develop using a more recent version (e.g. 3.0-rc1 or or the latest git version). This way, you can take ad...

It's not clear to me which version new users ought to be using - is 2.1.1 the most recently released "stable" version? I see there's a v3.0-rc1 from December but it's significantly behind the v3.0 branch. I suppose it's not technically released so do you want us to avoid it, or use it and report iss...

Ok, fair enough - probably too much effort for too little gain. So, "debouncing in software" in this context might be a simple FreeRTOS task with a (say) 10-tick delay that simply samples the GPIO regularly and debounces that (e.g. history comparison)? That's what I have been using with success, alt...

The two "classical" ways to debounce a switch in software involve either regular polling followed by a counter, delay or shift register, or use of an interrupt with a timestamp comparison to disregard spurious transitions. I had an idea to use the counter peripheral (PCNT) to debounce a switch - the...

As far as I know, nope. You need an FT2232, your cable has an FT232. Actually, I think the FT232 H is OK - it has an MPSSE so is basically a one-channel version of the FT2232. The FT232 R is not sufficient though. I have a C232HM-EDHSL cable (which is the same as the -DDHSL but 5V not 3.3V on the V...