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

[radiolistener]

At a glance a new bootloader beacon packet looks exactly the same as the old one, it just use different id. So, I can add support for this packet in a test version of the tool and it can start upload firmware with old packets. In that way we can bypass this step.

But it is unknown how the new bootloader will react on old packets for flashing. Since official flasher don't supports it, there is no way to check it. It is possible that it can accept old packets and flashing will be ok. But on the other hand it can reject it and in that case it should fail with no flashing and it should not affect the radio.

But there is some minor risk that sending old packets in response to the new bootloader beacon may be incorrectly interpreted in the new bootloader with unpredictable results... At worse case it may leads to incorrect firmware overwrite, so the radio will be bricked and may not start after that and will require to use new flasher which supports new bootloader (which is not available at this time) to restore it.

Unfortunately it is unknown when a new flasher which supports new bootloader will be available and there is some small risk that it will be never available (it means that such new radio with bootloader 5.00.01 will never support firmware upgrade, this looks highly unlikely, but still possible). So, if radio will be bricked it may needs to wait for a new flasher tool version which will have support for a new bootloader.


I already implemented test version of the tool, so if someone agree to test it on a new radio with bootloader 5.00.01, with take into account that there is some risk to brick it, just let me know.

[eXisten]

The conclusion is that you still have to wait - but either with a working radio or with a broken one Well, there's no fun without risk!
I hope that in the event of a failure I will be able to count on further assistance?
If so, I still have questions:
1. What firmware do you recommend for testing?
2. Should I perform a full reset on my device before flashing?
3. Assuming the operation is successful (I hope ), what effect will this have on the ability to program the radio using CHIRP or PSCPS?

[radiolistener]

Yes, we're needs to wait until someone who has radio with new bootloader will test it and there is no guarantee that it will works and will not brick the radio. But it's better to test it on one device and share results to other, so other peoples will know if it works or not and can avoid unnecessary risk of bricking the radio. If it will be tested by many peoples and it will brick the radio, it leads to a lot of bricked radio and it will be a stupid way...

I estimate the risk is not high, and if I had a radio with a new bootloader, I would test it without hesitation. The price of the radio is 15-20 USD and you don't lose it, you can use its component as replacement part for other radio (battery, charger, enclosure, antenna, PCB with all working elements include display, etc). And you can fix its firmware later, when new bootloader will be supported in a new flasher tools. So, I don't see there a big lose.

I expect that if it don't supports old flash write packet, it just will fail on first write packet and it don't brick the radio.

But there is some risk that it can brick the radio, and there is needs to be ready for that, this is why I don't share the test tool with new protocol support and will share it to the one people who understand it and is ready for that. If there is no such people, we're needs to wait when some other people will get the radio with new bootloader and will do research how it's new bootloader works. There is no other way... 


By the way. Did you tried to read EEPROM from the radio with new firmware 5.00.05?
If it don't works, can you share k5tool log file for -rdee command?

Note: EEPROM read should be executed when radio is working in normal mode, not bootloader

[radiolistener]

1. What firmware do you recommend for testing?

It don't matters, I recommend to use official firmware for the first test, to minimize risk with bugs in custom firmware.
For example RT590_v2.01.32_publish.bin, this is the best official firmware from my opinion.

The only thing that needs to be done before upload new firmware is to read full eeprom backup and keep that file. Later, it can help to restore original calibrations and settings if it will be broken with custom firmware.

2. Should I perform a full reset on my device before flashing?

You can do, but it don't matters.

3. Assuming the operation is successful (I hope ), what effect will this have on the ability to program the radio using CHIRP or PSCPS?

If you upload official firmware and it will works ok, it will be supported in software like CHIRP or PSCPS the same as it was worked before for old radio.


PS: before testing there is a sense to check if PCB hardware is the same as for old UV-K5 radio. If it uses new PCB hardware, there is high risk that old firmware will be incompatible... Can you share photo of PCB?

[eXisten]

Yes, E5TOOL reads EEPROM correctly.

Here is a photo of the PCB:

https://zapodaj.net/plik-qym6AWJa0Z

[radiolistener]

pcb has the same version as old uv-k5 and looks the same, so it should work ok with old firmware.

Since read eeprom works ok, it looks that the only change is bootloader.
So there is a chance that it can support old flash write packet. Needs to test it.

If it fails then this new bootloader uses new write packet, and needs further reverse engineering.


Here is patch file which add support for a new bootloader beacon packet for K5TOOL source code. If someone can accept possible risk of bricking device, please test if this patch helps to upload firmware to the radio with a new bootloader 5.00.01 and write here message if it works or not. Please share log file if it fails.

[eXisten]

What should I do with this file?

[radiolistener]

What should I do with this file?

you can apply it to source code, compile and test it.

Well, here is test version of k5tool which supports new bootloader beacon packet, it uses old flash write packets, so it's unknown if new bootloader supports it. There is a risk that it may not work on a radio with new bootloader 5 (or higher) and it include risk that it may brick the radio, because no one tested it with new bootloader radio. Use it at your own risk.

This test version also includes some minor fixed for write packet structure to be compatible with original flasher software, it will be committed soon to git-hub.

If you test it on a radio with new bootloader, please let me know if it works and share the log file.

[Chris79]

I've given it a go, but no luck. Here's the log attached.
Not bricked though. Just an endless beacon loop.

[eXisten]

Same for me. Nothing came of it, but the radio is alive
When I tried to load the Egzumer mod, it went into a loop - I had to close the terminal window.

====[UTC:2024-07-22T17:55:44]===================================================
[TRACE] Opening COM7
[TRACE] rx: abcd24006c6934e62f930f463d66850a24441690856c9de61bbf3d700f05e4403b0fe980166c14c6ffffdcba
[TRACE] RX: 7a052000010202061c53504a3747ff1093008900352e30302e303100280c000000000020
[TRACE] recv PacketFlashBeaconAck {
  HdrId=0x057a
  HdrSize=32
  Version="5.00.01"
  Data=010202061c53504a3747ff1093008900
}
[TRACE] send PacketFlashVersionReq {
  HdrSize=16
  Version=*EGZUMER v0.22
}
[TRACE] TX: 300510002a45475a554d45522076302e32320000
[TRACE] tx: abcd1400266904e604d44a1a747890123375d9ae245e14e6ecfbdcba
[TRACE] rx: abcd24006c6934e62f930f463d66850a24441690856c9de61bbf3d700f05e4403b0fe980166c14c6ffffdcba
[TRACE] RX: 7a052000010202061c53504a3747ff1093008900352e30302e303100280c000000000020
[TRACE] recv PacketFlashBeaconAck {
  HdrId=0x057a
  HdrSize=32
  Version="5.00.01"
  Data=010202061c53504a3747ff1093008900
}
[TRACE] send PacketFlashWriteReq {
  HdrSize=268
  SequenceId=0x1d9f8d8a
  ChunkNumber=0x0000
  ChunkCount=0x00ec
  Size=0x100
  Padding=0x0000
  Data=f03f00200b010000c1000000c300000000000000000000000000000000000000000000000000000000000000c50000000000000000000000c700000055590000cb000000cd000000cf000000d1000000d3000000d5000000d7000000d9000000db000000dd000000df000000e1000000e3000000e5000000e7000000e9000000eb000000ed000000ef000000f1000000f3000000f5000000f7000000f9000000fb000000fd000000ff0000000101000003010000050100000701000009010000fee7fee7fee7fee77047fee7fee7fee7fee7fee7fee7fee7fee7fee7fee7fee7fee7fee7fee7fee7fee7fee7fee7fee7fee7fee7fee7fee7fee7fee7fee7fee7
}
[TRACE] TX: 19050c018a8d9f1d0000ec0000010000f03f00200b010000c1000000c300000000000000000000000000000000000000000000000000000000000000c50000000000000000000000c700000055590000cb000000cd000000cf000000d1000000d3000000d5000000d7000000d9000000db000000dd000000df000000e1000000e3000000e5000000e7000000e9000000eb000000ed000000ef000000f1000000f3000000f5000000f7000000f9000000fb000000fd000000ff0000000101000003010000050100000701000009010000fee7fee7fee7fee77047fee7fee7fee7fee7fee7fee7fee7fee7fee7fee7fee7fee7fee7fee7fee7fee7fee7fee7fee7fee7fee7fee7fee7fee7fee7fee7fee7
[TRACE] tx: abcd10010f6918e7a41c925d213539401302e980e65314c625900d40e035d540d003e980166c14e62e910d402135d5401303e980166c14e62e910d402135d540d603e980166c14e62e910d40e635d540465ae980dd6c14e6e3910d40ee35d540c203e980c56c14e6fb910d40f635d540ca03e980cd6c14e6f3910d40fe35d540f203e980f56c14e6cb910d40c635d540fa03e980fd6c14e6c3910d40ce35d540e203e980e56c14e6db910d40d635d540ea03e980ed6c14e6d3910d40de35d5401202e980156d14e62b900d402634d5401a02e980e88bea01d076f3a751722ba7ede41767e88bea01d076f3a7dfd22ba7ede41767e88bea01d076f3a7dfd22ba7ede41767e88bea01d076f3a7dfd22ba7ede41767d75fdcba
[TRACE] rx: abcd24006c6934e62f930f463d66850a24441690856c9de61bbf3d700f05e4403b0fe980166c14c6ffffdcba
[TRACE] RX: 7a052000010202061c53504a3747ff1093008900352e30302e303100280c000000000020
[TRACE] recv PacketFlashBeaconAck {
  HdrId=0x057a
  HdrSize=32
  Version="5.00.01"
  Data=010202061c53504a3747ff1093008900
}
[TRACE] rx: abcd24006c6934e62f930f463d66850a24441690856c9de61bbf3d700f05e4403b0fe980166c14c6ffffdcba
[TRACE] RX: 7a052000010202061c53504a3747ff1093008900352e30302e303100280c000000000020
[TRACE] recv PacketFlashBeaconAck {
  HdrId=0x057a
  HdrSize=32
  Version="5.00.01"
  Data=010202061c53504a3747ff1093008900
}
[TRACE] rx: abcd24006c6934e62f930f463d66850a24441690856c9de61bbf3d700f05e4403b0fe980166c14c6ffffdcba
[TRACE] RX: 7a052000010202061c53504a3747ff1093008900352e30302e303100280c000000000020
[TRACE] recv PacketFlashBeaconAck {
  HdrId=0x057a
  HdrSize=32
  Version="5.00.01"
  Data=010202061c53504a3747ff1093008900
}
[TRACE] rx: abcd24006c6934e62f930f463d66850a24441690856c9de61bbf3d700f05e4403b0fe980166c14c6ffffdcba
[TRACE] RX: 7a052000010202061c53504a3747ff1093008900352e30302e303100280c000000000020
[TRACE] recv PacketFlashBeaconAck {
  HdrId=0x057a
  HdrSize=32
  Version="5.00.01"
  Data=010202061c53504a3747ff1093008900
}

[radiolistener]

I've given it a go, but no luck. Here's the log attached.
Not bricked though. Just an endless beacon loop.

Thanks a lot.

I see two possible reasons:
1) The new bootloader don't want to accept firmware version 3.
2) Developer of bootloader just removed old write unlock packet and replaced it with a new one.

To clarify which one we have, could you please test firmware update with manually specified fake version, for example 5.00.07?

Here is how to do it.
You're needs to unpack firmware and then flash it with -wrflashraw command and fake 5.00.07 version to unlock write:

Code: [Select]

$ ./k5tool -unpack RT590_v2.01.32_publish.bin
CRC check passed...
   Version: 2.01.32
Write RT590_v2.01.32_publish-2.01.32.raw...
Done

$ ./k5tool -wrflashraw 5.00.07 RT590_v2.01.32_publish-2.01.32.raw

Let me know the result.

If it don't helps, then it means that the new bootloader don't allow old write unlock packet. In that case we're needs to wait for official firmware updater or when someone can obtain firmware from the chip and disassemble it...

[radiolistener]

Same for me. Nothing came of it, but the radio is alive
When I tried to load the Egzumer mod, it went into a loop - I had to close the terminal window.

Thanks. egzumer firmware has version started from *, but bootloader still don't accept it.
We're needs to try to specify version 5 manually, if it don't helps, then the new bootloader wants a different way to unlock flash write...

[Chris79]

Attempted to unpack and flash with V3.
No success. Same beacon loop again.

[radiolistener]

Attempted to unpack and flash with V3.
No success. Same beacon loop again.

Thanks, it means that manufacturer removed old flash write packet support from the new bootloader. We're needs to wait for official updater tool to get more info.

I updated K5TOOL to v1.6: https://github.com/qrp73/K5TOOL/releases/tag/v1.6

It has fixed bootloader packets structure added error details for flash write operation, also this version prefers USB serial ports on linux.
And this version has a check for bootloader 5. For bootloader 5 this version will show not supported error.