We use cookies to provide our visitors with an optimal site experience. View our privacy notice and cookie notice to learn more about how we use cookies and how to manage your settings. By proceeding on our website you consent to the use of cookies.
I’m attempting to implement the CP2102N for USB programming of a STM32 microcontroller (via bootloader).
The CP2102N is enumerating correctly as a Silicon Labs Virtual COM port (COM16) on my PC.
However, UART communication does not seem to work (no activity on the UART traces when scoped).
I’ve gone through any software side issues I can think of and am suspecting a hardware issue. Attached photos show the final expected design and current board being tested (has the pink circled graphic).
A 3.3V LDO exists on the board (for testing purposes only supplies 3.3V when USB is connected), thus was decided to run the CP2102N in the self powered mode.
A mistake in the test board manual corrected by and VBUS is being attempted to be powered via the 3.3V net (as shown in pink markup) instead of a voltage divider directly off the USB port. As mentioned, for testing the 3.3V net should only go on when the USB is connected, so it seemed to be a potential temporary testing solution. From what I can see in the datasheet this temporary 3.3V net supply should work…
Any recommendations or suggestions are greatly appreciated.
C17 and C18 were intended to allow for a short pull of BOOT0 high and NRST low on the STM32 to allow switching into the bootloader automatically. This was based on some quick online references which suggest using RTS and DTR to do this in combination with series 0.1uF caps. I’m not sure if this truly viable. During testing I did temporarily remove these caps to separate from the ST, then toggled BOOT0 and NRST manually.
Hi Robert, as it is UART I assume RX goes to TX and vice versa correct? If so it is connected properly, perhaps it was missed but on the block below is where the connection is flipped:
… More context in earlier reply.
I’ve just double checked the layout as well ST pin 19 goes to 20 on the CP2102N and ST pin 20 to CP2102N 21.
Well, I’m not seeing anything glaringly wrong with your design. It’s indeed very strange that the device enumerates and you can connect to it, and yet you’re not able to initiate a data transfer. Just to confirm,
when you probe the TXD signal, it just stays logic high when you expect a data transfer?
you’ve tried streaming a large amount of data over the serial port to try and get that Amber LED flashing? (I’m thinking something like an infinite loop of serial.write("Hello World\n"); serial.flush();)
Do let me know whether you have any success with Linux or not. If not, then my only other thought at the moment is to consider that the MCU is somehow causing the issue. I see you have the SWDIO and SWCLK signals in place, so I assume you are able to connect with an STLINK? Perhaps you could flash a simple program which configures UART1 to send and receive data to/from the CP2102N. Doing so would ensure that pins PA9 and PA10 are configured properly and allow you to test whether data can be received by the CP2102N (and see if that Green LED starts flashing). You could also enter the bootloader by software using the option bits (Section 2.6 in RM0394) as sort of a sanity check. It would be good to be absolutely sure that the bootloader is running.
Hi @danieljj ,
I suspect that you have some of the flow controls on (Xon/off, DTR or RTS). Call SetCommState() with a structure where all the 3 handshakes are disabled.
A quick update. I’ve confirmed the actual UART connection is now working. I think there was an assembly defect, second reflow run of the CP2102N area seems to have resolved the issues?? As Matt suggested, I’ve gotten successful transmission from the STM32 over USB.
The TX/RX LED issue was just resolved, the GPIO functionality apparently comes disabled and needs to be programmed via SI Lab’s Simplicity Studio. Managed to find this document from a forum post online: https://www.silabs.com/documents/public/application-notes/AN721.pdf.
I’m still having issues getting into the ST boot loader, however managed to get 1 lucky entry in by timing the NRST pull down. I originally intended to use the DTR/RTS pins to work with CubeProgrammer’s DTR and RTS pulse control, but getting the timings seems tricky, might need to move to another solution.
I believe the original intent of this support topic has been resolved and marked accordingly.
For anyone coming across this:
DTR/RTS based BOOT0/NRST control is possible however, STM32 CubeProgrammer is very limited in pulse capability currently. The NRST timing sequence is very sensitive.
I ended up using an external python based script to get around this to manually control RTS for NRST.
