Skip to content
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

Open
wants to merge 1 commit into
base: main
Choose a base branch
from
Open

Conversation

JuantAldea
Copy link

@JuantAldea JuantAldea commented Jan 13, 2024

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:

  • 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)
  • 2.00.06 (UV-K5)

USB adapters chipsets:

  • CH341
  • PL2303

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
@JuantAldea
Copy link
Author

This greatly reduces the amount of retries and ceremonies I had to perform for flashing the radio.

@sq5bpf
Copy link
Owner

sq5bpf commented Jan 29, 2024

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?

@JuantAldea
Copy link
Author

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.

@JuantAldea
Copy link
Author

JuantAldea commented Jan 29, 2024

For instance, although maybe not so canonical:
Start the programmer first, then turn the radio on in flash mode. It won't flash, at least I get a "k5_receive: bad magic number", and stay there forever (until it times out...?).

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.

@ntoivola
Copy link

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants