I made this custom UART bridge using a CH340X but I can’t seem to get this microcontroller in boot mode, even manually. My assumption was to connect the BOOT0 pin to 3.3V and NRST to GND like other microcontrollers but it doesn’t seem to work. The microcontroller itself does not seem faulty because I’ve connected an ST-Link to it and connects perfectly AND I have multiple of the same microcontrollers which have the same problem. Otherwise the CH340X can transfer data fine to a different model of STM (STM32L0).
My guess is that this microcontroller has a different procedure for booting and I don’t know how to do it.
Thanks a lot.
https://www.st.com/resource/en/datasheet/stm32g041c8.pdf
According to the Reference Manual (RM0444), the boot mode is determined by the state of the BOOT0 pin and a few of the option bits. Looking at the table below, you can boot into system memory (i.e., the boot loader) by setting BOOT0 to ‘1’ as long as the option bits are configured correctly.
Super! Then it should be easy to check/modify the option bits using the STM32CubeProgrammer software.
Sorry, I’m confused how I’m supposed to change these option bits, you mind showing me exactly how I would do that? Thank you
Hi @tomz0840,
It’s covered in section 2.4 of the user manual.
Ok thanks, that worked. Last problem, I can’t seem to flash automatically and can only flash manually. Here is the wiring:
Note that VCC is 5V and VDD is 3.3V. It seems like when I plug in RTS to NRST it is automatically low even before I turn on STMCubeProgrammer. What is the issue here? Thank you for the help.
Hi @tomz0840,
I’m not sure what you mean by this. Can you explain further?
Sorry for the confusion. My point is that I cannot get the STM32 in bootloader mode using the DTR and RTS pins of the CH340X, but I can only get them in the bootloader by manually connecting wires to BOOT0 and NRST (BOOT0 to 3.3V, and NRST to GND).
It seems like RTS goes low (oscilloscope), but DTR does not go high at all. But even when I disconnect DTR and put it to 3.3V and connect RTS to NRST, CubeProgrammer just lags for a while and shows these error messages:
Again, thank you for the help.
Hi @tomz0840,
Sounds like this is expected behavior according to the CH340 datasheet…
The default DTR# is not output and is kept low by the external resistor, but the DTR# pin can be set to output high level or not output by the application program
Some other highlights from the datasheet:
MODEM interface signals contain: CTS#, DSR#, RI#, DCD#, DTR# and RTS# … All these MODEM interface signals are controlled and function defined by computer applications.
One-click download: The computer download tool program opens the UART, sets DTR# to high level, sets RTS# to low level and then high level, and the MCU enters the BOOT download program
My guess would be that the computer application (in this case, STM32CubeProgrammer) doesn’t support setting/clearing RTS# and DTR#. That, or the settings are incorrect. Does changing the RTS and DTR settings in the UART configuration pane change the way these pins behave according to the oscilloscope? You mentioned that you’ve had luck with the STM32L0. Were you using STM32CubeProgrammer for that as well?
Is RTS# going low and staying low, or just going low momentarily? If it’s the former, then you’ll be holding the MCU in reset and I would fully expect it to be unresponsive.
So I had luck with the STM32L0 for flashing, but not entering the bootloader. In the UART configuration, I set DTR to high and RTS to “Negative Pulse” (to me, this implies a short pulse to GND from high logic), but it seems to have the same behavior as the “Low” option (staying low for a few moments). The DTR pin does not go high at all.
I might consider making another board to see if there is something faulty with the CH340 itself to verify it isn’t a hardware issue.
Again, thanks for the help.
