ESP32 Forum

Wow!!! That is some serious diagnostic work and congrats on your skills for solving it. The lessons I come away with:

1. Assume nothing (i.e. that the board is working perfectly)
2. Buy 2 (or ideally 3) of everything and check that if A fails B and C also fail (or not)
3. Eliminate as many unknowns as possible (which is what you did by recreating down to the nth degree a working environment)

I'm very spooked by the story. If there was indeed an assembly issue with the board, that would lower confidence in just about any ESP32 en-devour using this board. If something doesn't work, then we have the risk that it isn't usage but is actual hardware issue.

A data point ... I believe this is the very first time I have personally come across a story where it was the ESP32 board that was being claimed to be the issue. Every other time it had been software (95% of the time) or connected hardware (5% of the time).

However ... the great news is that you got it resolved. What would have been brilliant (and I'm assuming that you didn't do this) would have been some high resolution photos of the flaws you found. Maybe you can entice someone from the production side of these devkits to comment. If it were me, I'd ask you to put it aside and immediately send you a new one with postage return for the one you have. I'd want to look at the failing board in depth to see if there is some root cause or pattern that could be attributed to the problem. Since the silk screening was subtly different from mine, I'd also want to understand in depth the history of your board. Was it an early one, a later one or one produced by an identifiable source?

Neil,

Rats! Didn't know why I didn't think to do the photograph! I have all the old parts, but I'm pretty sure that Espressif will not trust that I did what I said. We live in a world literally teeming with people who are less than truthful.

Despite that, it's definitely the pads for the WRoom variant that they wanted to keep for future revs/coproduction. Kicking myself for not looking at the pins first. I always blame myself, the developer, for not following instructions first. But given the hardware development we've done (we make our own boards for our 3D scanner), it should have come to me earlier.

Thanks for the kudos. More important, thanks for the extra set of eyeballs.

And if anyone else is out there (especially at Espressif), you should modify your solder stencils so that the WRoom pads do not get pasted on them when assembling the boards. This would reduce frustration like mine!!!

Last post on this...unless anyone else replies...

I originally bought 10 of the WRover modules from Mouser. Didn't realize how handy that would become...

Just spent a few hours hammering on a Wrover kit trying to get JTAG to respond. Finally I searched this board and found this.

Same problem!!! TCK is a hard short to ground. Grrrrrrr!
No way they are testing the JTAG functionality before shipping. Can't work!

I can do it, but I have no interesting in replacing the Wrover module. I'm shipping this thing back.

Regards,
Greg

Hi Greg,

Mercies and condolences for you, but also a hurrah that you did not spend as many DAYS as I did It is frustrating. In today's just-in-time world this is quite a problem... Easy to miss a design flaw like that. Easy to fix it too...just cut a different solder paste template! I didn't want to spend the time waiting....

Send me a Private Message if you wish to confer more over this. Personally, right now, I'm having a big problem with the BLE Uart and HID Keyboard devices not staying attached to Windows 10. On one of my Windows machines, it will, sorta. On the other, something somewhere is missing in the BT stack is communicating with the ESP32. Specifically, it's a Surface Pro I7, 2017 model. The driver for the Marvell BT device will clog up and eventually stop talking to all it's devices.

I didn't know buying a $4.20 part from Mouser would take me down the rabbit hole, but down I have gone, and in a BAAAAD way!

P.S. When I see "Regards" at the end of a letter, I think of someone on the other end of the planet. I love it, and since it's not customary closing for a letter over here, I'm always interested in knowing where folks are from. I think of our time as a global "mixer", so to speak. Despite the terrors out there, it's a great time to be alive and meet other folks...

Cheers!
GNorkus

FWIW, we're looking into how it can be that two boards with essentially faulty JTAG wiring could have passed through our QA inspection; it's supposed to test everything on the board, including JTAG connectivity. I've worked with JTAG enough to know it can be hard enough to set up as is, without also having to take into account hardware issues.

Great to hear you are looking into this!
I've ordered another Wrover-kit board from a different supplier. I'm hoping to get a good one from a different batch.

The board fails early in the process of the OCD script. An error something like "failing for all ones".
I'm running Linux, and I could see both USB device files when the board was plugged in. The board flashed on the 2nd USB device perfectly.

The board was purchased using Amazon in the USA, and the supplier is Olimex.

I haven't dropped it in the post office box yet, as I am planning to do so later in the week.
I'm in no hurry to ship it back, so I could ship it back directly to you if I could get reimbursed or trade for another board.
Please let me know if you would like to get this board for your analysis. I will keep it for now.

Regards,
Greg

Board received today from gridconnect.

The first thing I did upon unboxing was measure resistance JTAG TCK to ground. 5400 ohms. Great!!!

Next, I powered up the board, and successfully flashed the ESP-IDF sample "blink". This toggles GPIO 5, which is connected to the display so the entire display blinks. Works, great!

Next, run the openocd script, after adding the JTAG jumpers to the board.
First time success!

Open On-Chip Debugger 0.10.0-dev-ga859564 (2017-07-24-16:16)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
none separate
adapter speed: 20000 kHz
force hard breakpoints
Info : ftdi: if you experience problems at higher adapter clocks, try the command "ftdi_tdo_sample_edge falling"
Info : clock speed 20000 kHz
Info : JTAG tap: esp32.cpu0 tap/device found: 0x120034e5 (mfg: 0x272 (Tensilica), part: 0x2003, ver: 0x1)
Info : JTAG tap: esp32.cpu1 tap/device found: 0x120034e5 (mfg: 0x272 (Tensilica), part: 0x2003, ver: 0x1)
Info : esp32: Debug controller was reset (pwrstat=0x5F, after clear 0x0F).
Info : esp32: Core was reset (pwrstat=0x5F, after clear 0x0F).

Nice, both TAP controllers found. Excellent!
Now I can proceed with my JTAG experimentation.

Regards,
Greg

Hey Greg, we are interested in getting that board back; I'll PM you for details.

Hi ESP_Sprite,

When you get the board from Greg, can you let me know if it was the same thing that happened with my board? Specifically, it was the WRoom pads hidden underneath the WRover module. I gave the exact method of determination in the earlier post. Nice to see the company investigating....

Thanks!