firmware version barf

[jeffgi]

It's not a bug per se but I think I have an issue for uvk# radios going forward. I'm working with a recent uv-k6 from Amazon and a uv-k5(99) fresh from China. I suspect that the latest OEM firmware shipping is incompatible with establish protocols.

UVMod downloads firmware images. Both radios have the same 58,674 bytes firmware.
UVMod and several other modder softwares barf very early reporting No data received.

Python proves that drivers and cables are working. fwversion_read bombs with:
C:\jg\git2\amn02\Quansheng_UV-K5_Firmware\python-utils>python fwversion_read.py COM3
uvk5.uart_receive_msg<raw< abcd0800026910e6680d6224950bdcba
uvk5.uart_receive_msg<dec< abcd080014050400469c6f64b43edcba
Traceback (most recent call last):
File "C:\jg\git2\amn02\Quansheng_UV-K5_Firmware\python-utils\fwversion_read.py", line 14, in
print(radio.get_fw_version())
^^^^^^^^^^^^^^^^^^^^^^
File "C:\jg\git2\amn02\Quansheng_UV-K5_Firmware\python-utils\libuvk5.py", line 127, in get_fw_version
return reply[8:].split(b'\0', 1)[0].decode()
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
UnicodeDecodeError: 'utf-8' codec can't decode byte 0x9c in position 1: invalid start byte

i comment out line 21 of configmem_read and get:
uvk5.uart_receive_msg<raw< abcd0c000d691ce66e9e054067a9ba2421ebdcba
uvk5.uart_receive_msg<dec< abcd0c001b050800400f0800469c6f6432e8dcba
469c6f64

firmware_read.py is incompatible with 58,674 bytes firmware?
if 469c6f64 is a reasonable configmem, successful fwversion_read is no longer a prerequisite in configmem_read (and other readers)?

[amnemonic]

If there is no new version of firmware updater then it will be necessary to dump firmware using openocd to know if protocol changed or if 469c6f64 is indeed proper version number. Please check what version do you see in CPS software?

[jeffgi]

Thx. Latest chirp allows COM3 selection but gives "firmware '' not supported" CPS 1.0.40 again allows COM3 selection but Device, ReadIn gives "radio connection failed" Fwversion_read.py does reveal that the basic abcdXXXdcba structure is preserved but bombs at line127. At that line, .decode() fails with UnicodeDecodeError can't decode 0x9c invalid start byte. Most python files insist that non-failing fwversion_read is a prerequisite for other functions to functions. Cps and Chirp probably also implement that prerequisite. My current theory: My two radios always fail fwversion_read so any tool implementing that prerequisite will falsely fail.

…

On Mon, Feb 26, 2024, 11:29 AM Adam Mnemonic ***@***.***> wrote: If there is no new version of firmware updater then it will be necessary to dump firmware using openocd to know if protocol changed or if 469c6f64 is indeed proper version number. Please check what version do you see in CPS software? Clipboard01.png (view on web) <https://github.com/amnemonic/Quansheng_UV-K5_Firmware/assets/29899901/6a79dbea-03c9-42da-97f6-fc4d24cb50cf> — Reply to this email directly, view it on GitHub <#127 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AODQCHKYNXF4YBKXPRTME3LYVTIBJAVCNFSM6AAAAABDZFKJOKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSNRUHA2TMMRYHA> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[jeffgi]

from sq5bpf k5prog:
"... firmware version number is 16 bytes at 0x2000"
"if we send a * as the first char, then all known boot loaders will accept it"

so all modded bin files must have an '*' at 0x2000?

my current thought is to write a special byte (obfuscated and/or xor-ed) to 0x2000?

[amnemonic]

reveal that the basic abcdXXXdcba structure is preserved

exactly! which rules out bad cable etc.
Can you try CPS in version 1.0.41?

[jeffgi]

i got 1.0.40 from China download two days ago. not sure where to get .41 and not sure what new it might tell us.

is true:
"... firmware version number is 16 bytes at 0x2000"
"if we send a * as the first char, then all known boot loaders will accept it"
?

I'm looking for workable values to write 16 bytes starting at 0x2000 to current problem radios.

[amnemonic]

not sure where to get .41

Link to v1.0.41 is right in my previous reply.

not sure what new it might tell us

It can tell us if XOR key has changed as it looks like it might be the case.

is true
"... firmware version number is 16 bytes...

yes, that is true however if firmware upgrade application is not able to recognize version then it probably would not flash it or what is worse - will flash it incorrectly thus bricking it.

I'm looking for workable values to write 16 bytes starting at 0x2000 to current problem radios.

I would rather like to try to find cause of this problem and then think about proper solution.

[jeffgi]

thx. I read the .41 text and didn't notice it was also a link. my bad, sorry.

downloaded and un-rarred. two *.exe files with same English name ending with two different Chinese characters
ran both and both say
"
Launcher Error
Unable to open archive
"

[jeffgi]

firmware XOR change would explain my observations. if so, it would require two CPSs which might explain two CPSs in the .41 zip? Did you get either to run?

[amnemonic]

You must rename *.exe files and remove Chinese characters from filename, then it works fine :)

[jeffgi]

thanks. rename allows install of two CPSs (just for the record, one Chinese chars, other English chars)
v1.0.40 from May 2023 gives same results as v1.0.41 from June, 2023: "Radio connection fail"
CPS from early 2023 are uninformative regarding a oem firmware build from Nov 2023.
XOR still a good theory.