-
Issue building custom board with RP2040. (Board partially recognised by Windows)
Posted by atulravi on 29 Dec, 2023 19:43 -
(SOLVED) Hi forum readers!
I am currently working on a board powered by the RP 2040. The issue I face is that the board is partially recognized by Windows only when I rub the board on a metal sheet or if I rub my fingers over the crystal part.
The only deviation from the specified crystal part is that mine has a higher ESR while the Load Capacitance remains the same. I have 2 board iterations. One with a 27pF cap and another with 15pF in line with the crystal to ground.
The 15pF gives the error when I touch it while the 27pF gives the error when I rub it on the metal sheet. The error it gives is "Windows does not recognize the device".
I suspect that because of me changing the crystal brand/part the capacitance has varied which is preventing the chip from being recognized. The voltage levels on the 1V1 line are 1.09V and on the 3.3V line is 3.32V. That does not seem to really be the issue at the moment.
The crystal I have used (Since the Abracon one is not available locally) is the HC49SMD from YXC. Datasheet from the supplier: https://www.ktron.in/wp-content/uploads/2021/09/Crystal-HC49SMD-Datasheet.pdf
I mention about the touching and rubbing since I suspect that the capacitance values are creating issues. Based on calculations from the Adafruit article: https://blog.adafruit.com/2012/01/24/choosing-the-right-crystal-and-caps-for-your-design/ I get 13.5pF and instead used the 15pF caps which work when I touch. I also suspect that me using THT caps can also cause problems. But my inexperience shows.
The device is drawing 10mA as it should so no issues there. Windows device manager gives the descriptor failed error screen shot attached. I have not really modified analog part values from the main design guide given by RPi.
Another difference which I feel does not cause much of a difference is the TVS diode which is a SM712, but I don't think that causes much of an issue.
I have a rather crappy oscilloscope to really check the oscillations of the crystal. So, I cannot do much intricate measurements there. But I shall try my best.
Pictures of the boards, PCB pdf and scheme PDF are attached if anyone would like to check. Thanks a lot for your help in advance!
Pictures of the board with the 15pF cap and the 27pF caps are attached.
-
How did you solder the RP2040?
I ask because it has one ground connection and its the big square pad under the chip.
Did you use paste and hot air for that? -
How did you solder the RP2040?
The board has been assembled at a Fab and they used Hot-Air. But I don't think that is a major issue. But I may be wrong.
I ask because it has one ground connection and its the big square pad under the chip.
Did you use paste and hot air for that? -
Hmm, OK, do your trust the fab!?
The odd behaviour you describe could possibly be a grounding issue. Current normal 10mA but actual ground being used could be through an io pin or suchlike, if they didn't solder the RP2040 ground pad. Check your footprint has that pad, with copper exposed.
Other than that, I'm out of ideas. -
Hmm, OK, do your trust the fab!?
The odd behaviour you describe could possibly be a grounding issue. Current normal 10mA but actual ground being used could be through an io pin or suchlike, if they didn't solder the RP2040 ground pad. Check your footprint has that pad, with copper exposed.
Other than that, I'm out of ideas.
I think my trust reduced a bit just now. I hit the board with my Hot-Air station at 350 for a few seconds and instantly, the board upon connecting is giving the not recognised error. I should possibly pull it up and reflow it once again. Thanks for the suggestion. -
Hmm, OK, do your trust the fab!?
The odd behaviour you describe could possibly be a grounding issue. Current normal 10mA but actual ground being used could be through an io pin or suchlike, if they didn't solder the RP2040 ground pad. Check your footprint has that pad, with copper exposed.
Other than that, I'm out of ideas.
I think my trust reduced a bit just now. I hit the board with my Hot-Air station at 350 for a few seconds and instantly, the board upon connecting is giving the not recognised error. I should possibly pull it up and reflow it once again. Thanks for the suggestion.
yeah, I can conclude that it makes no difference, I re soldered the part and it is still not recognized. -
Maybe try interfacing with the board using SWCLK and SWDIO. Use it to check the clocks. You could upload a small program that outputs a frequency to a pin and then measure that for accuracy and stability.
I suppose your problem could also be the flash chip. Use the debugger to check that reading from flash is ok. Does the flash need to be preloaded with something for windows to recognize the device?
You are currently lacking enough information to debug, so these ideas are mostly for you to get more data points. -
You could also try feeding it a 12 MHz signal from a signal generator with the crystal removed. Just to verify that everything else actually works.
-
Maybe try interfacing with the board using SWCLK and SWDIO. Use it to check the clocks. You could upload a small program that outputs a frequency to a pin and then measure that for accuracy and stability.
I don't own a debugger so that is out of question as of now.
I suppose your problem could also be the flash chip. Use the debugger to check that reading from flash is ok. Does the flash need to be preloaded with something for windows to recognize the device?
You are currently lacking enough information to debug, so these ideas are mostly for you to get more data points.
My signal generator cannot give out a 12Mhz signal. It is limited to 1Mhz so that angle is cut. But I might have some go arounds around it. Maybe using a premade 12Mhz resonator and replacing the crystal capacitor circuit completely?
I could put in another flash chip since I have spares.
Regarding the flash needing to be preloaded, the design guide published by RPI mentions nothing related to it. And the design guide of Shawn Hymel also showed his board working upon plugging in for the first time.
The device works intermittently and especially when I expose the crystal area to different environments around it. So I suspect that the oscillator is not functioning properly since quite a few members on the rpi forum had mentioned that a bad oscillator will lead to no results even if voltages are correct. https://forums.raspberrypi.com/viewtopic.php?t=314935
https://forums.raspberrypi.com/viewtopic.php?t=345404
Shawn hymel's design guide: https://youtu.be/kcwvuwetgEQ?si=Yjc3zT7N_pgM8XV-
These are some of the pages I referenced, -
Maybe try interfacing with the board using SWCLK and SWDIO. Use it to check the clocks. You could upload a small program that outputs a frequency to a pin and then measure that for accuracy and stability.
I suppose your problem could also be the flash chip. Use the debugger to check that reading from flash is ok. Does the flash need to be preloaded with something for windows to recognize the device?
You are currently lacking enough information to debug, so these ideas are mostly for you to get more data points.
Since the CLK and DIO are part of the USB to serial protocol, I was wondering whether I could use the STLink since it seems to allow communication through that protocol. I may be wrong but that is a though that crossed my mind. Any thoughts? -
Something not clear (to me at least): does the MCU appear to run properly *only* when you touch around the crystal area, or does it run alright when left alone, but stops to when you touch the crystal area?
-
A 12 MHz oscillator in a package is less than 1 USD and much easier to get running than using a crystal. But if you don't have one on hand, you might want to try something different? You could use another rp2040 to generate a 12 MHz signal. That is by the way also how you debug using the two debug pins. It is all open source and free. Requires only a second rp2040 board to act as the debugger.
-
Since the CLK and DIO are part of the USB to serial protocol, I was wondering whether I could use the STLink since it seems to allow communication through that protocol. I may be wrong but that is a though that crossed my mind. Any thoughts?
No, it's SWD, which is a 2-wire variant of JTAG for ARM Cortex MCUs. What you need is a SWD probe. And if you have a STLink probe, it actually supports SWD. You should be able to use it for the RP2040, but certainly not with ST software tools. You'll need to use OpenOCD with it, select STLink as an interface and the RP2040 as the target. You'll find resources online for that. Teaching how to use OpenOCD and GDB (for debugging) is kinda beyond the scope of this thread about oscillator issues, and even beyond any kind of thread IMO, it's more like blog material.
Note that from your schematic, you haven't connected the 2 relevant SWD pins of the RP2040, so you're completely out of luck with this one anyway. Sorry. -
A 12 MHz oscillator in a package is less than 1 USD and much easier to get running than using a crystal. But if you don't have one on hand, you might want to try something different? You could use another rp2040 to generate a 12 MHz signal. That is by the way also how you debug using the two debug pins. It is all open source and free. Requires only a second rp2040 board to act as the debugger.
Using another Pico as a 12Mhz oscillator is something I never thought off. I should probably try that. I also received some help from Shawn Hymel who said that my oscillator design in general has some flaws.
Regarding the 12Mhz oscillator in a package, I have been searching for parts and have been hitting dead ends. Could anyone suggest a part I could replace the oscillator with? -
Since the CLK and DIO are part of the USB to serial protocol, I was wondering whether I could use the STLink since it seems to allow communication through that protocol. I may be wrong but that is a though that crossed my mind. Any thoughts?
No, it's SWD, which is a 2-wire variant of JTAG for ARM Cortex MCUs. What you need is a SWD probe. And if you have a STLink probe, it actually supports SWD. You should be able to use it for the RP2040, but certainly not with ST software tools. You'll need to use OpenOCD with it, select STLink as an interface and the RP2040 as the target. You'll find resources online for that. Teaching how to use OpenOCD and GDB (for debugging) is kinda beyond the scope of this thread about oscillator issues, and even beyond any kind of thread IMO, it's more like blog material.
Note that from your schematic, you haven't connected the 2 relevant SWD pins of the RP2040, so you're completely out of luck with this one anyway. Sorry.
I understand that not breaking out the SWD pins is a huge mistake from my end. But I could do some fine soldering and possibly connect some wires and try debugging.
But I am interested in replacing the whole oscillator circuit with a 12Mhz oscillator chip directly atm since it seems like a much better option.
I am also trying to see if there is a way I could use another Pico as a debugger directly instead of the ST Link. But this is something I will look into after the oscillator methods fail. -
Something not clear (to me at least): does the MCU appear to run properly *only* when you touch around the crystal area, or does it run alright when left alone, but stops to when you touch the crystal area?
I should've phrased my point better. When I rub my fingers over the crystal area, windows gives the "The last device connected is not recognised by windows" error. If not, windows does not even show that a device is connected in device manager.
So effectively, some sort of connection is established only when i rub my fingers over the crystal area. -
Ok. New finding. I get that error when I turn the USB C cable around and plug it in. It does not seem to be a crystal issue. This is perplexing. Considering replacing the USB C port with USB Mini to check.
-
I come bearing good news. It turns out that the stupid USB C port is creating the problem. I removed the port and replaced it with a data cable hard soldered and it works. So seems that the oscillator is good nonetheless. I suspect that the cable is bad. But it might also be the TVS diode creating issues.
Conclusion: USB C maybe good for consumers. But bad for my hardware development. I am never going to use it again.
Thanks a lot for the support! -
Conclusion: USB C maybe good for consumers. But bad for my hardware development. I am never going to use it again.
USB C is quite good IMHO.
If I avoided everything that didn't work first time for me, there is a lot I wouldn't know!
Don't let a mistake put you off it, just learn from the experience, that is the important thing. -
Conclusion: USB C maybe good for consumers. But bad for my hardware development. I am never going to use it again.
USB C is quite good IMHO.
If I avoided everything that didn't work first time for me, there is a lot I wouldn't know!
Don't let a mistake put you off it, just learn from the experience, that is the important thing.
Advice for life. I shall do that. I tried removing the TVS diode on one board and connected to see if anything happens. Still get the error. But my Frankenstein board where I have used hard connected USB A with wires works perfect. So, Cable may not support USB 2.0 maybe. I don't know. More to learn.
Lat Update: The TVS diode does work. So I suppose that that the cables are causing a problem. I also tried flipping D+ and D- polarity on the TVS diode and I get that error on windows then. I guess that is the root cause of issues. I shall stay away till I actually gain more information.
Thanks a lot for the support. -
A 12 MHz oscillator in a package is less than 1 USD and much easier to get running than using a crystal.
It's a proper step to debug the problem at hand, but I'm wondering about the general statement. I have little experience in this regard, but most everyone who used Parallax P8X32A (Propeller) on a breadboard did so using a crystal (and two capacitors). Not 12MHz, but typically 5 to 6.25MHz, but if it works on a solderless breadboard (with all its ill defined parasitary capacitances) it can't be that critical.
In regards to the stated problem: having the 'board' (the USB connection is established by the MCU alone) recognized by Windows is perhaps a too high level criteria. All kinds of things could go wrong. I'd try to define some smaller steps in order to be in a better position to tell what went wrong. Have the MCU blink an LED or output a square wave of a given frequency on one of its pins. I mean, one needs to determine whether the MCU is working at all or just marginally or is the timing just off or the clock instable ...
Good points. But it turns out that the crystal circuit is not the actual issue. I hope that you were able to go through the posts I made after regarding the actual issue which is related to the USB C port. Bypassing it fixed it. Now the board works perfect. -
I noticed you got it running. But here is a link to a 12 MHz oscillator package anyway: https://octopart.com/ecs-3225mvlc-120-cn-tr-ecs+international-127645426
-
Ah, part of the problem is the TVS diode SM712 that you have on the USB data lines. It has >70pF capacitance, way too much. You need to use low capacitance TVS, like 0.4pF or so. Search for USB TVS there are many to choose from e.g. USBLC6-2 for USB2 speeds.
-
Ah, part of the problem is the TVS diode SM712 that you have on the USB data lines. It has >70pF capacitance, way too much. You need to use low capacitance TVS, like 0.4pF or so. Search for USB TVS there are many to choose from e.g. USBLC6-2 for USB2 speeds.
Good catch. But I have also found another issue. Seems that I forgot to connect B6 and B7 pins of the 16 pin USB C connector and hence, I think it contributes to the issue as well. I cannot possibly solder wires to it. So, I now have 2 queries, Since I have effectively designed the board in such a way that the USB C only works in one configuration of the cable, should I get rid of the SM712 and interchange the data lines? would that work? Also Is there any way I could override those connections that have been missed?
Also the SM712 here is being used for ESD protection. So, I wonder what kind of effect it actually has since when i replaced the C port with a USB cable hard soldered, I just connected the data lines directly to the 27Ohm resistors bypassing it.
-
Also the SM712 here is being used for ESD protection. So, I wonder what kind of effect it actually has since when i replaced the C port with a USB cable hard soldered, I just connected the data lines directly to the 27Ohm resistors bypassing it.
Given that it’s rated for too high a voltage anyway, I doubt it’s doing anything. -
Yes it's a 12V TVS so not that well adapted here. But note that regarding the highish capacitance (as it was mentioned earlier), it was unlikely the issue. The RP2040 is USB Full-Speed only and from the specs, you're allowed up to 100pF of capacitance on the data lines in FS (AFAIR) - actually you may sometimes see recommendations of adding some small capacitors on D+/D- for USB FS to limit EMI, although the series resistors should be enough for that purpose.
A very low capacitance is only required for USB HS and above.
-
Seems that I forgot to connect B6 and B7 pins of the 16 pin USB C connector and hence, I think it contributes to the issue as well. I cannot possibly solder wires to it. So, I now have 2 queries, Since I have effectively designed the board in such a way that the USB C only works in one configuration of the cable, should I get rid of the SM712 and interchange the data lines?
You should connect A6 to B6 and A7 to B7. Then the connector will work both ways. -
Yes it's a 12V TVS so not that well adapted here. But note that regarding the highish capacitance (as it was mentioned earlier), it was unlikely the issue. The RP2040 is USB Full-Speed only and from the specs, you're allowed up to 100pF of capacitance on the data lines in FS (AFAIR) - actually you may sometimes see recommendations of adding some small capacitors on D+/D- for USB FS to limit EMI, although the series resistors should be enough for that purpose.
A very low capacitance is only required for USB HS and above.Yes it's a 12V TVS so not that well adapted here. But note that regarding the highish capacitance (as it was mentioned earlier), it was unlikely the issue. The RP2040 is USB Full-Speed only and from the specs, you're allowed up to 100pF of capacitance on the data lines in FS (AFAIR) - actually you may sometimes see recommendations of adding some small capacitors on D+/D- for USB FS to limit EMI, although the series resistors should be enough for that purpose.
Very interesting. In the next iteration, I shall consider some capacitors on the Data lines maybe.
A very low capacitance is only required for USB HS and above. -
Seems that I forgot to connect B6 and B7 pins of the 16 pin USB C connector and hence, I think it contributes to the issue as well. I cannot possibly solder wires to it. So, I now have 2 queries, Since I have effectively designed the board in such a way that the USB C only works in one configuration of the cable, should I get rid of the SM712 and interchange the data lines?
You should connect A6 to B6 and A7 to B7. Then the connector will work both ways.
[/quote]
So if I were to connect only A6 to B6, it should work in one direction alone right? (Considering the A7 is already connected and B6 is already connected)