 Notice. New forum software under development. It's going to miss a few functions and look a bit ugly for a while, but I'm working on it full time now as the old forum was too unstable. Couple days, all good. If you notice any issues, please contact me. |
Forum Index : Microcontroller and PC projects : PicoMite HDMI/USB USB Hub Issues
  Page 2 of 4   |
|||||
| Author | Message | ||||
| matherp Guru  Joined: 11/12/2012 Location: United KingdomPosts: 10064 |
Given both boards are the same I think we can assume that it is: 1./ a faulty batch of a particular component or 2./ an incorrect component fitted by JLC. Please check the values of R54, R55, and R56. Should be 12K, 15K and 4K7. R54 and R55 will take time to measure as there is a capacitor that needs to charge before they give the correct value. Looking at the circuit I now suspect R55 or R54. These provide a potential divider for the over-current protection and it looks like it could be the over-current is being triggered A hack solution would be to remove R55. That would prove the issue one way or the other. Edited 2025-03-01 20:45 by matherp |
||||
| birefringence Newbie  Joined: 25/02/2025 Location: GermanyPosts: 23 |
Sorry for the noise, I have just answered my own question: I bridged D2 with a clamp. Then I can connect a USB keyboard to PROG and it works fine. This proves that the problem is with the board and not with the Pico 2 or the firmware. |
||||
Mixtel90 Guru Joined: 05/10/2019 Location: United KingdomPosts: 7499 |
I've had my Chinese hot air gun for ages and not needed anything replacing. Just be sensible and don't use very low air flow at very high temperatures. Same as any other hot air device. You could try bridging R54. It's sometimes easier to bridge a SMD than take one off. The extra load on Q1 is nothing. Edited 2025-03-01 21:16 by Mixtel90 Mick Zilog Inside! nascom.info for Nascom & Gemini Preliminary MMBasic docs & my PCB designs |
||||
| birefringence Newbie Joined: 25/02/2025 Location: GermanyPosts: 23 |
The resistor values are correct. |
||||
| matherp Guru Joined: 11/12/2012 Location: United KingdomPosts: 10064 |
Try connecting either end of the fuse direct to 5V and then see if a USB device is then recognised. If that doesn't work I don't know what to suggest. If you want to ship me a board to have a look at then drop me a PM. Otherwise, one of the electronics experts in Germany may be prepared to have a look for you. |
||||
Sasquatch Guru Joined: 08/05/2020 Location: United StatesPosts: 376 |
I just had a thought, did you solder through the back of the PCB to the ground pad on U20? I'm not sure if it's strictly required for grounding, but it couldn't hurt at this point! All of mine are soldered. Edited 2025-03-02 04:38 by Sasquatch -Carl |
||||
| birefringence Newbie Joined: 25/02/2025 Location: GermanyPosts: 23 |
Yes, I did. |
||||
| birefringence Newbie Joined: 25/02/2025 Location: GermanyPosts: 23 |
Bingo! Using a crocodile cable clamped onto D2 and F1 makes everything work  It also continues to work if I remove the clamp while the board is powered until I reset it. |
||||
| matherp Guru Joined: 11/12/2012 Location: United KingdomPosts: 10064 |
Good news. I wonder if they have installed the wrong mosfet - should be a p-channel. Is LED3 definitely green if you put a diode test on it?. The easy workround is to remove the mosfet and short the pin to the fuse and the pid nearest C80 |
||||
| birefringence Newbie Joined: 25/02/2025 Location: GermanyPosts: 23 |
LED3 not only lights up when I put a diode test on it, it also lights up and stays lit with the 5V applied as well as removed again. So I guess the channel type of the mosfet is correct, as it stays conducting when pulled low. The markings are very difficult to read though, I think it says "S1" and "205" but I'm only guessing the second part. Could it be that your earlier guess about the over current detection triggering is correct? Applying 5V to the fuse would pre-charge C80, so no current is drawn during power on. |
||||
| birefringence Newbie Joined: 25/02/2025 Location: GermanyPosts: 23 |
To test this hypothesis I have removed R55. This, however, does not change anything. Now, I'm wondering whether I it is worth trying to remove R54 as well or if that could make things worse. According to the datasheet of the CH334F, OVCUR# it should have a weak internal pull up, so it should be OK to disconnect it. Edited 2025-03-02 20:48 by birefringence |
||||
| Mixtel90 Guru Joined: 05/10/2019 Location: United KingdomPosts: 7499 |
I can't find data on the MDD2301 mosfet. I wonder if something else has been substituted and the threshold voltage is too high for it to switch on? You could try shorting out LED3 (with R54 and R5 in place). Mick Zilog Inside! nascom.info for Nascom & Gemini Preliminary MMBasic docs & my PCB designs |
||||
| matherp Guru Joined: 11/12/2012 Location: United KingdomPosts: 10064 |
 Edited 2025-03-02 22:25 by matherp |
||||
| birefringence Newbie Joined: 25/02/2025 Location: GermanyPosts: 23 |
Yep, that works! If LED3 is shorted during power on, it starts up fine. So what is the easiest fix? Remove LED3 and replace it with a piece of wire? |
||||
| matherp Guru Joined: 11/12/2012 Location: United KingdomPosts: 10064 |
How brave are you feeling? Can you swap LED3 with the red ACTIVE LED? I specified a green LED because that is what the CH334 datasheet says. But for some reason you board(s) are not turning on the mosfet which suggests the forward voltage on the LED3 is too high or the mosfet itself has too high a Von. In theory red leds normally have a lower forward voltage than green. Please also check your 5V rail. Is it really a FULL 5V? even a couple of tenths down could be an issue. I measure a forward voltage of 1.775 volts on my green LED and my supply is 5.08 volts from a powered hub. Edited 2025-03-02 23:18 by matherp |
||||
| Mixtel90 Guru Joined: 05/10/2019 Location: United KingdomPosts: 7499 |
To try it you could simply hold a red LED over the green one. As the Vf for red is lower it will just take over. Just about any will do, it doesn't need to be SMD. You have to watch LEDs. The newer green ones are blue with a green phosphor coating. Vf is higher on those. Red is usually (but not always) safe as red phosphor over a blue LED isn't very efficient. . Edited 2025-03-03 00:48 by Mixtel90 Mick Zilog Inside! nascom.info for Nascom & Gemini Preliminary MMBasic docs & my PCB designs |
||||
| birefringence Newbie Joined: 25/02/2025 Location: GermanyPosts: 23 |
I tried to solder R54 back to the board I removed it from, but I just burnt it ... so I'm not very confident. My multimeter says 5.25V (from original Raspberry Pi power supply). I tried that with a red LED I found, for which my multimeter says 1.7V in diode tester mode. This did not work. I now discovered that the board, from which I removed R54, actually does work eventually if I press the reset button a couple of times while power is applied. Also, I tried to read the marking of Q1 with a microscope. I'm still not sure, but I would interpret it as "S1 20E". Edited 2025-03-03 03:03 by birefringence |
||||
| matherp Guru Joined: 11/12/2012 Location: United KingdomPosts: 10064 |
What do we now know? S1 is the correct marking for the MDD2301 The gate threshold voltage is quoted as typical -0.7V max -1.0V so that all looks good. You can turn on the transistor by bridging the LED so it isn't an over-current issue. It doesn't turn on reliably with a known good 1.7V red LED. Taken together, these don't make much sense unless the mosfet is way out of spec. What voltage do you measure of the CH334 side of the LED? Is the CH334 properly pulling the #PWRON pin to GND? |
||||
| birefringence Newbie Joined: 25/02/2025 Location: GermanyPosts: 23 |
When I just turn it on, I measure 3.27V so it is not pulled low. When I measure after getting it to work via shorting the LED3 or feeding 5V for a short time, I measure 35mV so it is pulled low then. On the board, on which I removed R55, the capacitor C80 slowly charges when power is applied. So all I have to do to get this to work is: 1) Apply power. 2) Wait until C80 is charged to well over 2V. 3) Press reset once. So I am not sure if the over current detection can be excluded. My current hypothesis is that Q1 is switching more slowly then expected, so that the charging current of C80 triggers OVCUR# due to the internal resistance of Q1 while it is not yet fully conducting. It works when C80 is pre-charged and it also works when the LED is bridged, because then the CH334F will be able to pull down Q1 more quickly. This could be tested by removing R54 as well, because that should fully disable the over current detection. I'm a bit hesitant to do it though, because I don't think I can put it back with my current equipment. |
||||
| Mixtel90 Guru Joined: 05/10/2019 Location: United KingdomPosts: 7499 |
It should start immediately if you remove R54 as well. If it doesn't (and it should if OVCUR# has an internal pullup) then just put a resistor from OVCUR# to 5V. Value not critical at all. A dead short would probably be fine but I like to play safe. :) The delay while C80 charges is probably because it's charging via the OVCUR# pullup. The charging current is holding OVCUR# down until it reaches the trip point to clear the overcurrent fault. You now need to use Reset to clear the fault. At that point PWREN# goes low, turning the mosfet on. I'll have to have a look at the CH334F data. I'd have thought that there would be a time delay on the OVCUR# input if capacitors are allowed on the output (and they should be according to the USB spec, I think). Mick Zilog Inside! nascom.info for Nascom & Gemini Preliminary MMBasic docs & my PCB designs |
||||
| Page 2 of 4 |
|||||
 Print this page |
 |
The Back Shed's forum code is written, and hosted, in Australia. | © JAQ Software 2025 |
