-
Notifications
You must be signed in to change notification settings - Fork 40
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Improve align-to-magic-word #22
base: main
Are you sure you want to change the base?
Conversation
This commit implements a byte-by-byte alignment approach. It consists on a state machine that consumes the UART output byte-by-byte, and that will only accept input of the form: `0xAB 0xCB, 0xXX, 0x00` . Additionally: * Corrects several memory issues (segmentation faults & leaks). * Reduces timeout lengths as they hinder the retry-realign process. Tested on Linux with bootloaders * 4.00.01 (UV-5R Plus), and * 2.00.06 (UV-K5) and adaptors based chipsets * CH341, and * PL2303
This greatly reduces the amount of retries and ceremonies I had to perform for flashing the radio. |
There have been already patches that improve syncing with the 0xab 0xcd sequence, so obviously there is some problem, but i can't reproduce it. Please tell me what you're doing that causes these out of sync problems, so that i can test these patches? So in other words: please help me replicate the errors, so that i can see the improvement from your patches. I use the usual baofeng-labeled cables with CH341 under debian 12. To flash I do ptt + turn on, connect the cable and run k5prog. And it works every time. How do i reproduce your problems? |
I don't do anything special as far as I know. Just turn it on and try to flash. With the patches you mention, patches that I already have, usually I have to either kill the programmer and restart it, or restart the radio, or both. |
For instance, although maybe not so canonical: That scenario works with my changes. Many cases implying a partial flashing, i.e., cancelling it with control+c, would lead to errors when trying to start another flashing, sometimes would even lead to a chain of errors (maybe something's left in the buffer of the serial converter?). Stopping a flashing and starting another one is something I often do while developing. |
For what it's worth, I experience the "bad magic number" issue quite frequently but have not been able to find any logic as to when it happens or what I might have done to trigger it. However, so far I have not experienced it once since applying this patch, so a big 👍 from here. I have the 2.00.06 bootloader and my cable shows up as "QinHeng Electronics CH340 serial converter" in lsusb. |
This commit implements a byte-by-byte alignment approach.
It consists on a state machine that consumes the UART output byte-by-byte, and that will only accept input of the form:
0xAB 0xCB, 0xXX, 0x00
.To me, this has greatly reduced the amount of retries I had to perform before flashing the walkie.
Additionally:
Tested on Linux with
Bootloaders:
USB adapters chipsets: