The 2021.11.9 update problem has been solved
. According to the hxd reminder in the comment, the problem has been successfully solved. It is a flow control problem. The specific solution is as follows.
Just turn off the flow control.
If you use the punctual atom or the code in the general, you also need to pay attention to the restrictions in the receiving function of the single-chip microcomputer, and use \r\n at the end, which is 0D 0A
This is a bug log blog, and no solution has been found so far
Recently, I used python for deep learning and image processing, and then sent packets to control the underlying STM32 microcontroller for control. However, when I use the STM32F1 development board of Puzhong Technology today, I can't communicate. After opening the port with pyserial, the microcontroller is stuck. Unable to run the program.
Hardware environment The phenomenon
of using the USART1 in the general computer and the host computer notebook to communicate . I have tried almost all the pyserial sending code and the underlying MCU USART bottom receiving configuration that can be found on the Internet, but it is useless. As long as the host computer pyserial opens the serial port, the microcontroller code will not move, and because the serial port is opened, I can't use keil5 to break the point in the program, an error will appear, and then the debug will be forced to close. But once pyserial closes the port, the code starts to run again. Test first from the software level: I can successfully communicate with the underlying MCU using the serial port assistant on the notebook side, which can eliminate the problem of the MCU serial port configuration and pyserial sends the package code. It can also communicate successfully when it is used on the B-type development board of robomasterDJI (the chip is STM32F407Z0G), and the python code problem is ruled out.
After all the helplessness, I checked the hardware diagram of the board in Puzhong, and found that CH340C may be making trouble, and it is very likely that CH340 resets the microcontroller forcibly.
Verification
After using pyserial to open the serial port, the microcontroller still does not run the code. But this time I put the power outage at the beginning of the program. Then use pyserial to close the serial port, sure enough! to the breakpoint. It means that the code is being forced to reset again.
I saw this post on the Internet,
but it may be different from mine. I still don't understand why the bottom layer of pyserial will cause the DTR port of the MCU CH340 to reset the MCU. If there is a chance in the future, continue to understand.