PCB Design Pitfalls #2: Nabd and Shabakah from v3 to v3.1

It has been a while since our last update. Nabd v3, Atlas v2 and Shabakah v3 have all been assembled and tested. However, not everything went as planned as the title suggests. We did notice a major flaw in Nabd and a minor flaw in Shabakah. On the brighter side, Atlas was all good! Let’s start with the good first.

Atlas 🌍 v2

Atlas v2 passed all tests and works great! The Espressif Systems MCUs and tools impressed us enough that we will probably update Atlas to utilize one of their MCUs as opposed to its current Microchip ATmega32U4. Very likely, but still TBD.

Nabd 🧡 v3 ➔ v3.1

Nabd v3 was almost perfect! Unfortunately, we have a design flaw that must be addressed with a board respin.

  • What’s the issue exactly?
    Well, we noticed that the 3.3V power good LED turns on even when 3.3V power isn’t supplied. We suspected it might be the new op-amp in our design. Perhaps we somehow had incorrect pinouts? So, we removed the op-amp:
  • The 3.3V LED still powered on after removing the op-amp. We then suspected it might be an issue with the 3.3V LDO itself. So we removed it and the MOSFET gate which controls 5V power output to the board and yet the LED still turns on? Something strange was going on…
  • Using a multimeter, we noticed a short between the 5V coming in from the USB and the 3.3V power line. But how? Taking a closer look, we discovered the source of the problem:
  • It turns out we overlooked a crucial setting in KiCad, “min clearance”. The 3.3V line is connected to the USB-C 5V line due to the board’s min clearance being set to 0 mm. The 3.3V out trace from the LDO crosses under the USB-C 5V line, and when it does, they get so close to each other that they actually connect.

This was a hard lesson, but a really good one to learn. Nabd v3 will require a respin, and that’s why we moved up to v3.1. Always double check your KiCad settings, especially the min clearance!

Shabakah 🕸️ v3 ➔ v3.1

Like Nabd, Shabakah was almost perfect too! However, we found a minor design flaw we overlooked. Thankfully, it didn’t stop Shabakah from working. The issue was a conflict between the UART and native USB D+/D- lines. We sometimes could communicate with Shabakah and upload code, and sometimes we couldn’t.

In Shabakah, we designed the USB-C port to connect to two different sets of USB data signals from two different sources; native USB D+/D- pins coming from the ESP32 and D+/D- pins coming from the CH340C IC (The CH340C IC handles translating the UART pins from the ESP32 to USB signals).

In hindsight, this doesn’t make sense, as these data lines will clash. And they did. To fix this issue, we cut the USB signal lines coming from the ESP32 and kept the CH340C USB signal lines. Lo and behold, the UART communication worked perfectly afterwards.

We will require a board respin to fix this design flaw. We knew a respin was likely, especially since we used a lot of new parts in v3. We also decided that what we need in the next revision of Shabakah is a switch that controls which set of USB data lines the USB-C port should connect to. Either the CH340C IC or native USB pins on the ESP32. We could also use two separate USB-C ports, but no, that makes Shabakah unnecessarily more complicated.

On a positive note, Shabakah’s new MCU, the ESP32-C3-MINI, has proved itself to be a great and capable MCU. We used it on a real-world project, and it worked flawlessly.

Additionally, development on Shabakah is easy, straightforward, and now it supports FreeRTOS! All thanks to the new MCU and tools developed by Espressif Systems.

Stay Tuned!

We hope this post can help people avoid some of our mistakes. The next and hopefully final revisions of our boards before they go up for sale are coming soon!

Leave a Reply

Your email address will not be published. Required fields are marked *