Date: Sun, 31 Jul 2022 12:40:59 +0000 From: bugzilla-noreply@freebsd.org To: bugs@FreeBSD.org Subject: [Bug 265533] uchcom: baud rate is not correct for CH34x Message-ID: <bug-265533-227@https.bugs.freebsd.org/bugzilla/>
next in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D265533 Bug ID: 265533 Summary: uchcom: baud rate is not correct for CH34x Product: Base System Version: CURRENT Hardware: Any OS: Any Status: New Severity: Affects Only Me Priority: --- Component: kern Assignee: bugs@FreeBSD.org Reporter: trombik1973@gmail.com the symptom is that, when uploading code with avrdude, sometimes the result= is successful, but not always. I have dozens of Chinese clones of arduino nano with CH340C. uploading fail= s on about 6 of 10. usually ends up with `expect=3D0xWHATEVER, resp=3D0xfc`. dur= ing the process, some commands get proper replies, such as `Device signature =3D 0x= 1e950f (probably m328p)`, others do not. this seems like a baud rate issue. the Linux kernel driver had a similar issue in the past. but recent kernel = does not, which was verified on Fedora 36. avrdude on the Fedora can upload code= to all the problematic nano boards. after reading this report on GitHub, i was convinced that the uchcom(4) has issues. https://github.com/nospam2000/ch341-baudrate-calculation when `uchcom_calc_divider_settings()` is replaced with the one in NetBSD, a= ll boards work. Sometimes, I am facing issues when avrdude verifies the flash content, but I am not yet sure what is wrong. could not find common denominators yet. at least, uploading always works with old bootloader (boud rate 57600), and new bootloader (115200). --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-265533-227>