Quansheng UV5 (new 2024 V5.00.03) wont allow FW change or chirp. Any Clues?

[minsik]

Hi guys.
This is a recent 2024 new Quansheng UV5 (new 2024 V5.00.03) which wont allow FW change or chirp. Any Clues?

Goes into FW mode, then they complain there was a problem and wont proceed. Seems version 5.00.03 returns something other than expected bytes when trying to  even use chirp. It complains the version is wrong and wont proceed. any clues how to update the firmware to say egzumer  or use chirp with this newest radio. Looks the same as one I purchased earlier and yet that works fine. This one all black and yet other wise is labeled UV-5R PLUS Output power = 8W. (hmmmm)  FCC ID-xbpuv-k5.

Used K5prog to backup ok. Trying to use K5prog to upload firmware this is what happens. 
------------------------------------------------------------
listening for firmware update mode packet ..
sending k5_hello ..
  firmware version: '5.00.03'
has custom AES key: no
 is in lock screen: no
         challenge: 05 DD 4F 4F
------------------------------------------------------------
obviously the change in supplied firmware is different from previous.   
Surely people are starting to see these around??

[radiolistener]

Can you please try my tool for fw update and share the log file with communication details if it reject fw update or eeprom read/write?

https://github.com/qrp73/K5TOOL/releases/tag/v1.4

I would like to see log files for the following commands, it will help to understand what is going on:

Code: [Select]

k5tool -reboot

k5tool -rdee 0x0000 0x2000 eeprom-0000-2000.raw

k5tool -wree 0x0000 eeprom-0000-2000.raw

k5tool -wrflash <firmware filename>

Each k5tool execution replaces previous log file, old log file is moved to the file with .bak extension, the old file with .bak extension is removed. So copy log file after each command. The log file appears in the current folder.

If your system has several serial ports, it may require to specify which serial port is connected to the radio, just add -port option:

On Windows:

Code: [Select]

k5tool.exe -port COM3 -reboot
On Linux:

Code: [Select]

./k5tool -port /dev/ttyUSB0 -reboot


The command

Code: [Select]

k5tool -reboot
just reads firmware version then reboot the radio and read bootloader version.

The command

Code: [Select]

k5tool -rdee 0x0000 0x2000 eeprom-0000-2000.raw
reads full eeprom backup.

The command

Code: [Select]

k5tool -wree 0x0000 eeprom-0000-2000.raw
writes eeprom backup file to the radio

The command

Code: [Select]

k5tool -wrflash <firmware filename>
uploads new firmware to the radio. It expects official firmware format (packed and encrypted).

If you're want to upload raw (upacked and decrypted) firmware image, it can be done with

Code: [Select]

k5tool -wrflashraw 2.01.32 <firmware filename>
where 2.01.32 is the version string which will be send to the radio to unlock firmware write.

But note, there is no way to check if raw firmware is valid and not corrupted. It's better to use official firmware format, because it allows CRC checksum check.

[ftg]

It seems that in V5 the firmware image format the bootlaoder in the radio accepts seems to have changed.
I'd ask on the UVK5-Dev Telegram group, as others are also working on that V5 firmware issue.

I have a new one enroute, so we'll see if it also has V5 firmware and if SWD is still accessible enough to dump the firmware.

[radiolistener]

it's impossible to say what is going on without logs.

Technically the firmware version doesn't affect ability to update firmware, because firmware update is performed from bootloader which is not a part of firmware and remains unchanged. But if there is new bootloader it's possible, that it can break existing firmware update tools.

You can check bootloader version with:

Code: [Select]

./k5tool -reboot
For example, I got new UV-K5 and it cannot accept firmware update. k5prog shows some strange incorrect response. And detailed investigation shows that the radio just sends bootloader beacon packet, but unable to listen for incoming packets from PC. k5prog just thought that echo is a response from UV-K5. I discovered it with my k5tool. So, it seems like RX line on my new UV-K5 is broken, probably defective chip.

This is the reason why I wrote k5tool - to get ability to see detailed communication log in order to investigate issues.

The log of k5tool contains full communication details, include raw sent/received data in hex, decrypted hex data and human-readable parsed packets. So you can see all details what is sent and what is received and can understand what happens.

In addition k5tool allows to convert firmware from packed to unpacked format and from unpacked to packed format and also it has UV-K5 bootloader simulator mode for testing other UV-K5 firmware update software (in simulator mode it also writes the same detailed communication log).

[ftg]

On telegram the current consensus seems to be that the packing format for the firmware has changed.
It is hoped that it is not AES instead the previous XOR.
AES is not out of the question, as the factory firmware update tool and the firmwares apparently support it. Just that it was not used.

[radiolistener]

On telegram the current consensus seems to be that the packing format for the firmware has changed.
It is hoped that it is not AES instead the previous XOR.
AES is not out of the question, as the factory firmware update tool and the firmwares apparently support it. Just that it was not used.

in this case it should not affect ability to upload firmware from existing firmware images, because old UV-K5 uses plain upload format and unpacking is done on firmware update tool side. It just makes it harder to decrypt the new official firmware file images.

From my point of view, it may be due to defective radio or it may be due to they changed bootloader version and now it requires different packets format.

In any case it's impossible to decide what is going on without the log file.

[ftg]

It absolutely does affect uploading old firmware images if V5 is deliberately not backwards compatible.
Even the V4 firmware was not available from the vendor site when it started shipping, it was dumped from radios.
So the old update tool with old firmwares not being compatible wiht the new V5 firmware makes sense.

And yeah, it is not possible to go much further without a device at hand or logfiles.

Additionally, I do have one UV-K5( where the programming connector was damaged by a faulty cable and that one now also refuses to program.
I'll have to solder in some wires for more reliable updates in it.

[radiolistener]

It absolutely does affect uploading old firmware images if V5 is deliberately not backwards compatible.
Even the V4 firmware was not available from the vendor site when it started shipping, it was dumped from radios.
So the old update tool with old firmwares not being compatible wiht the new V5 firmware makes sense.

if you upload V5 firmware (taken with SWD for example) into old radio, it will not stop accepting old firmwares, because firmware is accepted with bootloader, not by firmware. When you update firmware it don't touch bootloader which remains on the top part of memory (above address 0xf000). The new firmware is flashed from bootloader code, not from firmware code.

So, this issue is definitely not related with firmware version. It may be related with a new bootloader version, which will break support for official firmware update tool either. Or it may be related with some UART defect on the radio. Or it may be related with version signature which is send to unlock firmware write.

There are possible many issues. In order to find what is going on exactly, there is needs to capture log files taken on problematic radio.


It appears that broken UART on a new UV-K5 radio happens very often. I suspect that probably someone tried to connect bad accessory to the radio (with high voltage or something like that, it may be some headset or programming cable) and it damage UART RX line on the radio. Then they return the radio back and seller selling it again to a new buyer. And since it happens very often, probably there is probably present some bad accessory for the radio, which damage UV-K5 accessory port and many peoples catch in that issue.

Another possible issue is production defects.

So, if you're get new UV-K5, it's mandatory to test it's accessory port, there is a high risk that you get returned radio with damaged accessory port.

[ftg]

The only information we have about the new firmware running on the device is that it reports V5.00.03 as it's version.
The bootloader was likely also updated by the factory.
Radios that shipped with V5 firmware not being updatable nor flashable with the current tooling is not an isolated incident.

[radiolistener]

what is the version of bootloader on problematic device?

[A.Z.]

@radiolistener

just an idea, add to your tool an option, say --logappend which will force it to append to the current log instead of overwriting it, I think it may be useful

[Vadym]

Hello @radiolistener.
It would be very helpful if your K5TOOL will support firmware's read feature.
I raised issue for feature at GitHub,
https://github.com/qrp73/K5TOOL/issues/2

Thank you for K5TOOL

[radiolistener]

It would be very helpful if your K5TOOL will support firmware's read feature.

There is no way to read it with known bootloader packets.
Technically it is possible to make modded firmware which will support packet to do it, but since it needs to upload such modded firmware to the radio, there is no sense to read it back.

[ftg]

Just received my "new" UV-K5(8 ) and based on initial testing the programming connector in is bad.
As received it was incredibly stiff and did not accept the programming cable.
Had to push in a more robust 3.5mm connector to it a few times for it to loosen up and allow the programming cable to properly bottom out.

k5prog-win just showed this in endless flood in programming mode:


K5TOOL gave this as a response to hello:


And the same for attempted reboot:


I'll try it with an additional cable later today and see if it was just my cheap programming cable or something else.
If it does not work with the other style cable either, I'll solder in an USB UART direct to the MCU UART pins and see how things work then.

[radiolistener]

K5TOOL gave this as a response to hello:


And the same for attempted reboot:

Did you tried it when radio was turned on in a usual mode? I'm asking because your screenshot shows that the radio sends bootloader beacon packet which happens when radio in bootloader mode (turn on with pressed key to get LED on).

-hello and -reboot commands should be send in a normal mode (when radio is working), it will not works in bootloader mode.

The bootloader mode is intended to upload firmware. And since your radio reports bootloader 2.00.06, it should works ok to upload firmware. This is standerd version of bootloader. If serial port is not broken of course...

It shows error, just because you're trying to send hello packet when the radio is staying in the bootloader mode.
When the radio is in bootloader mode, it supports only -wrflash and -wrflashraw commands.

In order to use -hello and other commands, you're needs to disconnect the cable, power on the radio in usual mode and then connect cable.


Before flashing new firmware, take full eeprom backup, because custom firmware may modify some calibration data. You can read eeprom backup when radio is in usual working mode (not bootloader mode when LED is on and nothing on the display).

Bootloader mode => -wrflash and -wrflashraw commands only
Normal mode => -hello, -rdee, -wree, -rdadc, and other commands, but NOT -wrflash and -wrflashraw.

[A.Z.]

Won't it be useful to add a "sniffer" function to k5tool so that it will be able to detect if the beacon mode is active ?

[radiolistener]

Won't it be useful to add a "sniffer" function to k5tool so that it will be able to detect if the beacon mode is active ?

Just released v1.5: https://github.com/qrp73/K5TOOL/releases/tag/v1.5

Now you can list available serial ports:

Code: [Select]

$ ./k5tool -port
/dev/ttyS0
/dev/ttyUSB0

Added -sniffer command, it works in read only mode, it just monitor serial port communication and prints decoded packets to console.

Also added -parse and -parse-plain commands it get hex data as argument, parse it and prints decoded packets to console.
-parse is used for packets with envelope (encoded)
-parse-plain is used for a plain packets without envelope (decoded)

for example:

Code: [Select]

$ ./k5tool -parse abcd2800036930e66bd657156c7087606533c7b2246c14e62e910d402135d5401303e980166c14e62e910d40decadcba
48 bytes
rx: abcd2800036930e66bd657156c7087606533c7b2246c14e62e910d402135d5401303e980166c14e62e910d40decadcba
RX: 1505240045475a554d45522076302e32320000000000000000000000000000000000000000000000
recv PacketHelloAck {
  HdrSize=36
  Version="EGZUMER v0.22"
  HasCustomAesKey=0
  IsPasswordLocked=0
  Padding[0]=0x00
  Padding[1]=0x00
  Challenge[0]=0x00000000
  Challenge[1]=0x00000000
  Challenge[2]=0x00000000
  Challenge[3]=0x00000000
}
Done

$ ./k5tool -parse-plain 1505240045475a554d45522076302e32320000000000000000000000000000000000000000000000
40 bytes
RX: 1505240045475a554d45522076302e32320000000000000000000000000000000000000000000000
recv PacketHelloAck {
  HdrSize=36
  Version="EGZUMER v0.22"
  HasCustomAesKey=0
  IsPasswordLocked=0
  Padding[0]=0x00
  Padding[1]=0x00
  Challenge[0]=0x00000000
  Challenge[1]=0x00000000
  Challenge[2]=0x00000000
  Challenge[3]=0x00000000
}
Done


[ftg]

...
Did you tried it when radio was turned on in a usual mode? I'm asking because your screenshot shows that the radio sends bootloader beacon packet which happens when radio in bootloader mode (turn on with pressed key to get LED on).

-hello and -reboot commands should be send in a normal mode (when radio is working), it will not works in bootloader mode.

The bootloader mode is intended to upload firmware. And since your radio reports bootloader 2.00.06, it should works ok to upload firmware. This is standerd version of bootloader. If serial port is not broken of course...
...

You were entirely correct and this was user error on my part.

Both the cable and radio port worked fine.
Flashed latest IJV firmware to the radio successfully with K5TOOL.
Nice to have an additional tool in the arsenal.
 
This also confirms that my 6/2024 stickered radio does not have the new V5 firmware.
The serial number might also point towards week 26 of 2024 as the manufacturing date, which would be in June and correspond with the sticker.



So still waiting to encounter a unit with V5 firmware so that I can dump the FW and bootlaoder with SWD, assuming it still works.

Edit:
Forgot to mention that K5TOOL annoyingly seems to default to /dev/ttyS0 on linux, not /dev/ttyUSB0.
It's a minor annoyance, but an annoyance it is.

[A.Z.]

Won't it be useful to add a "sniffer" function to k5tool so that it will be able to detect if the beacon mode is active ?

Just released v1.5: https://github.com/qrp73/K5TOOL/releases/tag/v1.5

Thank you, another suggestion, let's say you change the "Logger" code this way (note: AIR CODE !)

Code: [Select]

        static Logger(bool bAppend)
        {
            try
            {
                FileMode fm = Filemode.Create;
                const string fileName = "K5TOOL.log";
                if (File.Exists(fileName))
                {
                    if (bAppend)
                    {
                        fm = FileMode.Append;
                    } else {
                        var fileNameBak = fileName + ".bak";
                        if (File.Exists(fileNameBak))
                            File.Delete(fileNameBak);
                        File.Move(fileName, fileNameBak);
                    }
                }
                _stream = new FileStream(fileName, fm, FileAccess.ReadWrite, FileShare.Read);
                _stream.Seek(0, SeekOrigin.End);
                LogToFile(string.Format("====[UTC:{0:yyyy-MM-ddTHH:mm:ss}]{1}",
                    DateTime.UtcNow,
                    new string('=', 80-4-25)));
            }
            catch (Exception ex)
            {
                Error(ex);
            }
        }

and then add a new parameter "-keeplog" to the tool, when such a parameter is specified the constructor "bAppend" flag is set to True, otherwise it will be False, such a mod would allow to keep the log in case one wants to run the tool several times in a row to perform some checks, that way the output will go to a single log w/o overwrite (append to existing log)

[radiolistener]

Edit:
Forgot to mention that K5TOOL annoyingly seems to default to /dev/ttyS0 on linux, not /dev/ttyUSB0.
It's a minor annoyance, but an annoyance it is.

This is strange, it just use the last one from the port list reported by OS.
So, it expects that the last connected device should be used as default.
At least I think that it should work in that way. 

It appears that your system reports ports in reverse or random order.
Could you please run k5tool with empty -port option? It should show port list in the order reported from the OS:

Code: [Select]

$ ./k5tool -port
/dev/ttyS0
/dev/ttyUSB0


Added fix to prefer /dev/ttyUSB* devices as default. Try it, let me know if it works. The fix is already pushed to git source code.

[eXisten]

Hello!

I got a new radio on monday (Quansheng UV5R Plus - interesting, because my unit has a USB charging port and I don't think it should) and unfortunately I am not able to change the firmware. All the methods I know don't work. I managed to make a copy of the configuration and calibration files, program the channels via CPS (CHIRP reports an unsupported version - 5.00.05).
K5TOOL reading shows:
firmware 5.00.05
bootloader 5.00.01

I don't know what to do - i guess, i can only wait for a solution... 

Regards - Rob.

[radiolistener]

K5TOOL reading shows:
firmware 5.00.05
bootloader 5.00.01

I don't know what to do - i guess, i can only wait for a solution... 

Can you please share k5tool log file taken when you're trying to upload firmware?

[eXisten]

Sure, is it about this data?

====[UTC:2024-07-20T08:57:43]===================================================
[TRACE] Opening COM7
[TRACE] rx: abcd24006c6934e62f930f463d66850a24441690856c9de61bbf3d700f05e4403b0fe980166c14c6ffffdcba
[TRACE] RX: 7a052000010202061c53504a3747ff1093008900352e30302e303100280c000000000020
[TRACE] recv Packet {
  HdrId=0x057a
  HdrSize=0x0020
  Data=010202061c53504a3747ff1093008900352e30302e303100280c000000000020
}
[ERROR] Unexpected response Packet {
  HdrId=0x057a
  HdrSize=0x0020
  Data=010202061c53504a3747ff1093008900352e30302e303100280c000000000020

[radiolistener]

yes, thanks. It shows that they changed bootloader to version 5.00.01 which uses different packets. Needs some time to to research it.

Did you tried official flasher tool?

I can build new test flasher version that supports this new bootloader packet, but it needs to be tested and, there is no guarantee that it can work because there is possible other changes that we don't know. There is possibility that it can brick the radio and it will require to wait for new bootloader support in flasher tools to unbrick it. Can you agree to test it?

[eXisten]

Yes, I tried - with no effect. When you click the "connect" button, the "update" field turns off and cannot be used.
Would I agree to test your tool? Hmm, tempting, but still risky - the question is how much This requires deep consideration
Any way, I will be grateful for sharing any new information regarding work on figuring out the new bootloader

Regards - Rob.