I immediately plugged them in and neither board showed up on my computer over USB on either main board.
I found already in my house:
1x nRF52840 processor board (WRL-16984)
1x QWIIC Carrier Board - Single (DEV-17723)
I then:
Connected the nRF52840 to the QWIIC board and it appeared on my computer over USB (my existing processor and carrier are good)
Swapped the nRF for the new ESP32 on the QWIIC board, and the ESP32 appeared on the computer over USB (the ESP32 processor board is good, both actually)
Installed the nRF on the Main Board - Double and it would not appear over USB
=> the main board - double is bad. Actually, both are bad.
This seemed strange to me, so I emailed support. They sent me out two new Main Board - Doubles which I received today. Neither of them work, same as above.
I’ve tried the above process multiple times with both main boards and the QWIIC carrier. Same results.
Same USB cable, computer, and USB port for every test.
A few other nuggets:
USB power is coming through, I see both power LEDs lit
Power is getting to the processor, I see the processor LED blinking, code is running
Bootsel and Reset both work, so the board is seated properly enough to get GPIO
I note that on the plastic bag, the lot numbers on all four boards are the same (Batch: 151656)
I have a hard time believing SparkFun sent me four broken boards. Anybody know what I’ve done wrong here?
It’s quite unusual that Sparkfun has a whole lot of bad products. Do you have another USB cable? If yes, you can try with that. These cables often make problems.
There is no logic on either mainboard between the USB-C and Micromod connector, so it might be the cable (as proposed already)
I have had major issues getting an nRF and SAM51D board working on a Micromod-main double. It took weeks to figure out and in the end, it all had to do with sketch serial1-calls and the Sparkfunboard library.
Just a question about the LED blinking on the nRF. Is there a pattern in it (short blinks, long blink ?)
Which sketch have you loaded on the nRF ? I can then try that as well.
LED - the blink pattern is mine. While waiting for my replacement main boards, I did some work with the ESP32 attached to my functioning QWIIC carrier and put a more unique “lub-dub” light pattern in.
Cables - I bought my cable because it was good quality and reliable for development. It’s a 3 ft, USB-A to C cable. However, I tried with two other cables this morning: a 3 inch and a 10 ft, both USB-A to C. Same behavior on both. And they all work with the QWIIC board, so they’re not power-only cables.
I’m running MicroPython on one ESP32 and the other is unmodified (so probably running Arduino). However, that shouldn’t matter. The ESP32 SparkFun used on the micromod doesn’t have native USB, so they included a CP2101. There’s none of my code required for the USB to work. It should just do it’s thing and enumerate.
I do have a multimeter. As far as I can tell, there’s continuity from the usb connector up to the ESP gold fingers, but it’s very hard to probe and requires seating the processor board halfway in. The CP2104 is on the backside, so I can’t get to the pads.
A diode check from the USB connector with the ESP32 board installed seems to confirm connectivity for both D+ and D- to the CP2104 (correction from earlier post, it’s not a CP2101, it’s a CP2104). That would seem to imply there’s a signal integrity/design problem here. I pulled up the PCB and there’s a rather large break in the ground plane under the differential pair. I’d say that was an issue, even at 12 MHz (full-speed USB), but I don’t see a lot of threads on the forums about this board. So it must be working for somebody?
What else did you have in mind that I should probe?
I have just taken my 3 x Micromod Mainboard Double ( 2 x batch 145760, 1 x 145733). Installed the ESP32 Micromod. I got /dev/ttyUSB0 (Ubuntu/Linux) on all 3 of them.
I had updated recently the ESP32 board library. As I am working on Ubuntu where Python is replaced with Python3, I had a couple of challenges getting it compiled and uploaded. It tried to find python instead of python3. But once I solved that I uploaded the default, standard BLINK sketch. Uploaded and worked without any problem on all three
can you make a picture of the " I pulled up the PCB and there’s a rather large break in the ground plane under the differential pair. "
else I have really NO idea what could be causing this.
I’m using Linux as well, and I do not even get /dev/ttyUSB0 with the same configuration. After that, I don’t think any of the software really matters since the USB is handled by its own IC (the CP210x). Are you able to tell if you have CP2102 or CP2104 on your ESP32 board? (lsusb and/or watching journalctl when you plug in will tell you).
Sorry, I was a bit loose with my language on the PCB comment. I pulled up the Eagle files for the PCB on my computer to see how signals were routed and I noticed that a big 3.3V trace was routed through the ground plane on the bottom layer and it cuts right under a whole bunch of signals going to the M.2 connector, including the USB. This creates a break in the ground plane under the differential pair which is known to cause signal integrity problems (ground return paths and all). But it’s generally tolerable with full-speed USB. The fact that your configuration works tells me it’s likely fine in this case because the USB is so slow. Intuitively that makes sense too since a) I’ve done similar things in the past with no issues, b) I don’t see a rash of complains on these forums.
A few other things I did:
I probed 5V and 3.3V, they’re fine
There’s no way to reset the CP2104, so I shorted across D1 to bring the 3.3_EN line low (it has a pull up) and disable the 3.3V regulator as a way to reset the CP2104, nothing changed
The only difference I see is the batch number between your ESP32 and main boards. All four of my main boards are from the same batch and different from yours.
I have a hard time believing SparkFun sent me four broken boards. Anybody know what I’ve done wrong here?
Well believe it, they did. I just got 3 of the same boards from the same batch which had the same issue. Pins 3 and 5 on J1 carrying D+ and D- were unsoldered along a few others on the back side of J1, FC0 and FC1. I soldered them since I’m too time crunched to return them. If you don’t have magnification and a fine tipped soldering iron to check all pins and repair, you should demand tested replacements. I let them know via the contact form and just got a “we’ll look into it response”. The right move for them now would be to send everyone who bought boards from the batch free replacements since they now have 7 confirmed defects in the same batch. AOI or functional testing would easily catch this issue but this exact issue seems to indicate Spark Fun does zero or very minimal inspection/testing in production.
I think I’ve been ordering from SparkFun for almost 20 years and I don’t think I’ve ever gotten a defective part. Must have been a bad batch that slipped through QA.
I assume when you repaired your board it worked?
I needed my boards before I left for work travel, and there’s nothing I can do to fix them on the road. It does look like there might be some disconnected pins on J1, but it’s hard for me to tell.
I also have an open support ticket with them. Hopefully they see this and can send us some tested ones!
