Can you be more specific about what's not working, or what is working? Does the TX LED fire when you send data? Or is the laptop not detecting the device at all?
Sorry I meant the laptop is not detecting it.
Www.Georgehobby.wordpress.com
Equipments: DSO104z, Hakko FX888D, Brymen BM869s
My experience is with the CP2102, not the "N", and I've always had USB provide power to the chip. So I may not be the best one to help with this. But some things to check:
If it's recognized on any other computer, then it would be a driver problem on your laptop.
Your schematic doesn't show the origin of the +5V supply, but make sure it's turned on.
This will sound silly, but make sure the pinout of your USB connector is correct.
You should have about 3.3V at Vdd.
I'm not sure the resistor values on VBUS are right. You have them both at 1K, which would give you 2.5V on VBUS. But Figure 2.6 in the data sheet, and the note at the bottom of page 5, suggest that you need to have at least 2.7V for the chip to recognize that the bus is connected, and they show 22K and 47K as the resistor values, which would put you at 3.4V at VBUS when connected.
It's handy to have a few Ebay CP2102 modules handy for checking out drivers and such. You plug one in, you get the USB-connected tone, and it shows up as a COM port in Device Manager. They are $2 or less.
Thank you Peabody, Appreciate it.
The main reason of using a CP2012'N' and not CP2012 was that i did not find any circuits online with this IC that incorporated the TX and RX led which was important for me and the datasheet of CP2012 did not mention anything about it but the N model did till i bought a USB to upload sketch to my Arduino but tracing the pins was quite hard on an SMD so i just stick to what was mentioned in the 'N' datasheet.
]I'm not sure the resistor values on VBUS are right. You have them both at 1K.....
I was just testing if that would work but turns out that was the problem here as far as i can see. Thanks for pointing it out.
Secondly would it be ok to power the USB side seperately by the source connected like for example a laptop or a desktop and still have the PCB running also at the same time and share the same GND plane as well ? Here the +5v comes from the PCB itself which is also used to the power Atmega328.
I was told that the USB and the PCB should not have different power supplies while running used the same power from the PCB.
The CP2102 doesn't have the LED output pins that the N has. So designers have just put the LEDs on the TXD and RXD lines. Apparently it worked ok so long as you didn't try to go too fast. But the N will go much faster than the CP2102, so I think they had to put in the separate LED driver pins. I think you picked the right one.
I don't think I understand what you're asking about power sources. The problem with the VBUS pin is an example of what you have to think about when there are separate power supplies to different parts of the circuit. In your circuit, you have the V+ source provided by the USB cable when it's connected, and you have the +5V supply from your circuit that powers the CP2102N. The problem arises when you plug in the USB cable before you power up the N. If USB V+ was directly connected to the VBUS pin, and if the cable is plugged in before the N is powered up, then there would be 5V on the VBUS pin when VREGIN is at zero volts. That violates the Absolute Maximum ratings for voltage applied to any pin. The resistor divider is supposed to mitigate that.
So anytime you have separate supplies, you have to consider the order in which things will be powered up. If you powered the CP2102N from USB V+, then everything on the N side would power up at the same time, and you wouldn't need the VBUS resistors. But then you would have a problem at the other end with the CP2102N's pins TXD, RXD, DTR, and RTS connecting to the ATmega328 at 3.3V when the processor is still powered down. You would have to check the 328's data sheet to see if that causes a problem. I believe in that specific case that the 328 pins will tolerate that, but you would have to check. If my memory is right about that, you might want to look at powering the CP2102N from USB.
I should also say that one disadvantage of the way you have it set up now is that the CP2102N will be powered up when the 328 is powered up, and that may be wasting a lot of current if USB is only used occasionally.
One way to avoid all these problems is to have USB power up everything when it is being used, and switch off the 328's regular power supply.
One question - is your 328 a 5V part? The CP2102N TXD, etc., will all be at 3.3V. It might work anyway, but it would be better if they matched.
I should also say that one disadvantage of the way you have it set up now is that the CP2102N will be powered up when the 328 is powered up, and that may be wasting a lot of current if USB is only used occasionally.
A wasteful 195uA.
One question - is your 328 a 5V part? The CP2102N TXD, etc., will all be at 3.3V. It might work anyway, but it would be better if they matched.
It will work fine. There's no need to match voltages.
If i understand, correct me if am wrong, a better design would be to power the CP2012N via the USB and i could avoid the voltage dividers there by reducing cost and BOM and the Tx and Rx would not be a problem either though they would be at different voltage compared to the 5v on the PCB used to power the Atmega328.
If i understand, correct me if am wrong, a better design would be to power the CP2012N via the USB and i could avoid the voltage dividers there by reducing cost and BOM and the Tx and Rx would not be a problem either though they would be at different voltage compared to the 5v on the PCB used to power the Atmega328.
I'm not sure. It would be a more typical design, but not necessarily better. If you power the CP2102N from USB, then when that chip is powered down, if the TX and RX pins of the Atmega328 are high, you could have an Absolute Maximum problem on the RX and TX pins of theCP2102N. Then there is the issue of the RTS pin. You show that as connected to RST. Is that the reset pin of the Atmega? If so, keep in mind that all the pins of the CP2102N will sink some current when it is powered down. So if RTS is connected to an active-low reset pin on the Atmega, that may keep the Atmega in reset, which is not what you want. The typical solution for that is to put a capacitor in series, so you can do a reset pulse, but there's no DC connection.
If Monkeh is right about the 195 uA and the 3.3V-5V issue, then except for needing the two resistors, your current design is pretty safe, and should work well.
If there is any voltage matching problem, I believe you can convert the CP2102N to a 5V device by driving Vdd with 5V - just connect Vdd to VREGIN. That shuts down the 3.3V regulator, and drives all the chip internals and outputs at 5V. I would be curious to know what others think of that idea.
In addition to what has already been said
- for any malfunctioning or failing USB device, you should be checking the most low level host output. For example with a Linux host, you'd look at dmesg right after plugging in the device. Things like swapped D+ vs D- will typically show up there as the host tries to enumerate the device at the wrong speed, and various device firmware or electrical noise issues will cause an initial recognize but later errors.
- Any malfunctioning QFN IC needs to have the interface between the metalization and the PCB pads inspected under high magnification, often holding the board at an angle rather than straight on. Even allegedly first rate assembly houses can fail to produce good results, especially if it's a new board design that might have less than ideal thermal properties, a bad paste mask, etc. And of course hand assembly always needs to be verified. Micro or mini USB connectors should be inspected, too.
- Always try a different cable, host, with or without a hub, etc...
Haven't use the CP2102 in a while, so I don't recall the the capabilities. However if you want to power a target board via USB with over 100mA then you have to have the CP2xxx negotiate for the power first, then allow power to be switched through (and not before).
Here's an implementation with a different chip (FT232L) but same idea: Q1 doesn't allow USB 5V through to target board until "PWREN" is switched.
If there is any voltage matching problem, I believe you can convert the CP2102N to a 5V device by driving Vdd with 5V - just connect Vdd to VREGIN.
You cannot.
Last year I ran across a batch of CP2102 modules from Banggood with micro-USB connectors on them. All of their I/O pins were about 4.3V. After lengthy discussions on the Silabs forum, we concluded that the explanation was that the modules had traces connecting /Reset (pin 9) directly to the USB 5V V+ line, instead of to Vdd where it belonged. The 5V at pin 9 was passing through the protection diode, which was connected to Vdd, with a diode drop. So the entire innards of the chip were being run through that source. The 3.3V regulator was effectively shut down since Vdd was already over 3.3V, hence no need to pass anything through. Cutting that trace, and leaving pin 9 floating, returned the I/Os to 3.3V.
The thing is, except for the 4.3V, everything seemed to work fine, at least at low current levels that didn't challenge that protection diode.
So I wondered whether just deliberately connecting the USB 5V V+ line to Vdd might convert the chip to a 5V part. There may be all kinds of reasons why that won't work, but it did work at 4.3V, so I think there is some chance that it would work at 5V too. But of course there's nothing in the data sheet that would suggest this is permissible.
So by the way, if you get a CP2102 module with micro-USB, check the "3.3V" voltage before connecting it to a 3.3V processor.
Just to have better idea at where should be, i've attached the schematic of the Atmega with the CP2102N. i probably should have posted it earlier.
You show that as connected to RST. Is that the reset pin of the Atmega ?
yes it is, the Reset pin is pulled up with a 10K resistor to +5 which is connected to the RST through 0.1uf cap on the CP2102N.
If so, keep in mind that all the pins of the CP2102N will sink some current when it is powered down. So if RTS is connected to an active-low reset pin on the Atmega, that may keep the Atmega in reset, which is not what you want.
I doubt this would be a problem when the Atmega Reset pin is pulled up to +5 with a 10K in series.
So all comes down to two designs, existing one with a 22.1K and 47.5K voltage divider instead of the two 1K resistors connected to Vbus. Second would be bus powered (preferred) mentioned in Page 5 within the datasheet.
With the schematics attached, would there be any reason why bus powered would be a bad idea ? and is it ok to have separate plane for the USB side. Would it be a problem for the Rx Tx pins in anyway ?
Why your voltage divider resistors are 1K? with Vbus 5V and both 1K resistors of voltage divider you will get 2.5V. While in datasheet they used 24k and 47k which gives 3.1V. This could be the reason. Chip detects the PC by getting voltage on VBUS pin. Probably with that voltage divider you are not crossing the threshold.
So all comes down to two designs, existing one with a 22.1K and 47.5K voltage divider instead of the two 1K resistors connected to Vbus. Second would be bus powered (preferred) mentioned in Page 5 within the datasheet.
With the schematics attached, would there be any reason why bus powered would be a bad idea ? and is it ok to have separate plane for the USB side. Would it be a problem for the Rx Tx pins in anyway ?
I don't see any problem using the bus powered version. The only theoretical problem is that if you power up the CP2102N via USB before you power up the Atmega, the 3.3V levels on Tx and Rx of the CP will exceed the voltage limits on the Atmega's Rx and Tx pins relative to the Atmega's Vcc, which at that moment will be at ground. But you have 1K series resistors which will limit any current flow, so I think that's ok. And you will see a lot of designs done that way. And if you always power up the Atmega first, even that theoretical problem goes away.
That said, there's also nothing wrong with the self-powered version you started with, with the correct resistor values on VBUS.
However, I need to ask you to double-check the Tx and Rx connections between the two chips. Those need to be connected in a crossover configuration - the Tx line coming out of the CP should be connected to the Atmega's Rx pin, and vice versa. From your schematic, it looks like you have Tx connected to Tx, and Rx to Rx, and that won't work. But that could depend on your labeling conventions, so I'm just asking you to make sure they are actually crossed over.
As for ground, you really need to get the opinion of some of the pros in here. I think you would need to assume that the ground of USB is ultimately referenced to earth. If the Atmega circuit, including the 5V supply, is floating, then I think you should be able to connect the two grounds. But if it is earth referenced too, then you need expert advice an that. I would do something simple like seeing if my voltmeter shows any potential between the two grounds when there are no connections between the two circuits, but that may not be a valid test. You need someone with formal training to answer this, and that's not me.
I've connected the USBv+ to the Vbus on the CP and checked the voltage at VDD i can see a 3.2v still the laptop does not detect with board when connected. What am i doing wrong ?
However, I need to ask you to double-check the Tx and Rx connections between the two chips. Those need to be connected in a crossover configuration - the Tx line coming out of the CP should be connected to the Atmega's Rx pin, and vice versa. From your schematic, it looks like you have Tx connected to Tx, and Rx to Rx, and that won't work. But that could depend on your labeling conventions, so I'm just asking you to make sure they are actually crossed over.
Thanks for pointing that out to me. I did think of it at design but forgot to correct before fabricating the board. Still learning from my mistakes.
That said, there's also nothing wrong with the self-powered version you started with, with the correct resistor values on VBUS.
That would just waste 195uA as suggested and more over i went with that design earlier because i did not get the whole thing about "same GND and same +5v voltage from different source". This post has really helped me understand it better.
As for ground.....
Yes the PCB is floating but i wish to have the USB side of the PCB in its own GND plane. Was hoping somebody could really advise me on that, would appreciate it.
I've connected the USBv+ to the Vbus on the CP and checked the voltage at VDD i can see a 3.2v still the laptop does not detect with board when connected. What am i doing wrong ?
If you have V+ also connected to VREGIN, and D+ and D- wired correctly, then I think it should work. I don't know what to suggest.
Thanks all seems to be working now after i had connected Vregin with Vbus+.
Now i need to enable the Tx and Rx feature on the IC and am not sure how it can be done on Simplicity Studio. I've downloaded and opened Xpress configurator, not sure how to go forward.
Thanks all seems to be working now after i had connected Vregin with Vbus+.
Now i need to enable the Tx and Rx feature on the IC and am not sure how it can be done on Simplicity Studio. I've downloaded and opened Xpress configurator, not sure how to go forward.
If you mean enable Tx and Rx on the CP2102N, I think all of that just works by default. Assuming you have the regular VCP driver installed on your computer, you should be able to bring up the CP's COM port in any terminal program, send data, and watch the LED blink. Or you can connect Rx to Tx, and loop back what you send.
It would be unusual if you needed to configure the CP in any way unless you are doing something strange.
Did you install the Driver ?
It would be unusual if you needed to configure the CP in any way unless you are doing something strange.
This particular models requires the Rx and Tx (GPIO pin 0 and 1) to be enabled to act as Tx and Rx. Got that also figured out, i had placed the LEDs in reverse, changed it and all looks good. I am not sure if that feature is enabled by default. I did set it though. So am not sure if it was the LED that i had placed or the enabling the PIN.
He means TXT and RXT, not the data lines.
It would be unusual if you needed to configure the CP in any way unless you are doing something strange.
This particular models requires the Rx and Tx (GPIO pin 0 and 1) to be enabled to act as Tx and Rx. Got that also figured out, i had placed the LEDs in reverse, changed it and all looks good. I am not sure if that feature is enabled by default. I did set it though. So am not sure if it was the LED that i had placed or the enabling the PIN.
Well congratulations on getting this part of your project working, anishkgt. It's nice when things work.
Well thank you couldn't have done without a little help from the community.
Though Vregin is shorted to Vbus, the datasheet recommends uning the voltage divider for optimum operation. Now with the voltage divider, the voltage at Vregin is 3.1v so would it be ok to short it to VDD as it has the same voltage ?