Problem with USB2412 hub and CP210 - Page 1
Forum section: electronics / projects

author: Dan_8123
author_rank: Contributor
timestamp: January 25, 2024, 07:54:43 pm
content: I have built a custom ESP32 board that includes a USB2412 hub and a CP210 UART bridge; unfortunately, I keep running into the issue that the USB2412 does not deliver power to the CP210 most of the time. I literally have to power cycle the board 10 times until the CP210 turns on!The CP210 implementation is based on the ESP32-C3-DevkitM1 reference design except that VBUS (pin 8 ) is powered by the hub so it's only powered when an USB upstream device is connected... At least that's how it's supposed to workIt's as though the hub does not detect the presence of the CP210 and therefore does not deliver power to it. I can manually enable power delivery by applying 3.3V to ENB (pin 4) of the MIC2026 and then the CP210 gets powered and everything works fine but this obviously isn't much of a solution.Anyone run into this issue before or can tell me where I've gone wrong?

author: wraper
author_rank: Unknown
timestamp: January 25, 2024, 08:52:21 pm
content: Where is USB shield GND connection? FB2/FB6 probably do more harm than good, especially if they have high resistance. C20/C19 are waste of parts. You'd be better with using internal LDO of CP2102 and power it from VBUS. Using mic2026 just for CP2102 VBUS input is ridiculous as it's just a logic input that detects VBUS presence and you could just connect it to PRTPWR2 pin directly with no voltage divider and leave OCS_n2 disconnected, or connect it to VBUS_DET pin of USB2412.If USB ports are working otherwise, the problem could be because MIC2026 is working incorrectly due the lack of any capacitance on its output and FLAG (overheating/overcurrent) output becoming active (low). BTW PRTPWR outputs have nothing do with detecting USB sink device before applying power as you wrote.By adding D1 between USB_IN and USB_T, you very likely violate minimum VBUS voltage in many possible circumstances, not to say you don't even use MIC2126 for USB_TAG but use it elsewhere where it shouldn't even be present.

author: wraper
author_rank: Unknown
timestamp: January 25, 2024, 09:05:22 pm
content: I edited the post above so you may need to reread it.

author: Dan_8123
author_rank: Contributor
timestamp: January 25, 2024, 09:24:46 pm
content: Shield:There isn't one, inside the device I am using 4-pin PicobBade connectors for USB. It's a low-speed signal and haven't run into any issues omitting the shield.Beads & C19/20:This is based on SMSC's evaluation board design but thanks for the input, I'll definitely take a closer look at that.D1:Already removed on the prototype, it was causing issues with unwanted backfeeding into the powersupply, forgot to update the schematic.MIC2126:Originally I used the MIC2126 for the USB_TAG too but it's a PCB that needs to be powered at all times which is why I bypassed it. Overall fair point though, just left it in because SMSC had it in their design but now that you mention it it definitely makes more sense to keep it simple.

author: wraper
author_rank: Unknown
timestamp: January 25, 2024, 09:32:38 pm
content: Quote from: Dan_8123 on January 25, 2024, 09:24:46 pmSo you are passing USB data signals through ferrite bead on GND and no functional shield connection. Also it's not low speed at all as USB hub IC is a full blown hi-speed USB device.

author: __greg__
author_rank: Newbie
timestamp: January 26, 2024, 12:45:39 pm
content: have You tried removing R12, R13 & R23 at the same time?To make sure NON_REM0 and NON_REM1 = 1 at startupand make ports 1 & 2 non-removable?

author: wraper
author_rank: Unknown
timestamp: January 26, 2024, 01:45:54 pm
content: Quote from: __greg__ on January 26, 2024, 12:45:39 pmReading this, I looked into datasheet, which confirmed something fishy going on here, and then into eval board schematic where R20 and R24 are marked as DNP (do not populate). Pull-up/down resistors should not be present at the same time. And LED should be connected to the same rail as strap resistor.

author: Dan_8123
author_rank: Contributor
timestamp: January 26, 2024, 02:10:11 pm
content: R20 and R24 weren't populated on the board so both REM0 and REM1 were pulled down, gotta get more disciplined with continuously updating the schematicI have now pulled both REM0/1 high since the devices are fixed and removed LED4 altogether since it's not really needed.I also removed the MIC2026 and that seems to have done the trick, the CP210 reliably shows up.@wraper, just out of curiosity, you mentioned that the ferrite beads can do more harm than good in some situations, could you elaborate?

author: wraper
author_rank: Unknown
timestamp: January 26, 2024, 02:45:47 pm
content: Quote from: Dan_8123 on January 26, 2024, 02:10:11 pmIf there was a shield properly connected to GND and this wire running in parallel, it would simply add more DC resistance/voltage drop. If it was a low speed device with no shield requirement, you'd somewhat screw up signal integrity by adding it in current return path for data signals. But as it's a hi-speed device, no shield connection is absolutely unacceptable, especially combined with this ferrite bead.