2025-10-08 10:18 AM - edited 2025-10-08 10:23 AM
I am having some issues with getting UART uploading working. I can read the chip and get it's ID, but it keeps saying it cannot get acknowledgments.
Everything is directly connected. Serial TX/RX to their corresponding pins and RTS to Boot and DTR to Reset.
At first, I thought it was because the FT232RNL chip has flipped polarity, but we can change this through the FTDI programmer.
After changing it, I am still having the issue above. Looking online, I see some people put a cap in between the DTR and Reset. Is this actually required? I know they did not on Arduino's. but I always though it was because their bootloader required it since there was no boot pin like on the ST's.
I cycled through all the possibilities for the DTR and RTS configuration in the ST Programmer software, but none of them seem to fix the issue.
Any guidance on this?
Solved! Go to Solution.
2025-10-10 8:30 AM
I believe I found the issue. The STCubeProgrammer software makes a new connection every single time you want to read/program. The issue is that it triggers the port to reset, which leads to rts and dtr being pulled low for a moment. You can't fix this with with inverting the rts and/or dtr because it will just pull it to the opposite direction for a moment. So, the issue is that during the connecting phase, it will always pull the chip out of boot mode when used in conjunction with the STCubeProgrammer due to the momentary port reset that happens.
So, to get this to work, i would need to do the following...
Make sure the boot pins are in the right states (boot0 high, boot1 low for this chip), then trigger a low pulse to put the chip in reset, then once the pulse goes back high, it will enter boot mode. Once I finish uploading the code, i need to reset the chip once more, but take the boot pins out of the programming before doing so. But this needs to happen AFTER I make a connection. Does that sounds right?
So basically, TLDR, I can't use the STCubeProgrammer because I can't control the initial sequence of events.
2025-10-15 11:17 AM
Final Reply....
Yes, this was due to the FT232 reasserting pins after a connection. I tried this on a CP2102N (after the grueling IDE download), and it worked once I preprogrammed the dtr and rts to the correct initial state.