Help! Bricked UV-K5 here

[Lar-Sen]

I was too confident about near unbreakable attributes of our favorite device... but this time it's for good. Was playing with 0x0516 bootloader command. Now I painfully discovered (it's related to NVRAM programming EDIT: it is not EDIT2: It indeed IS! the command blindly program a 106 byte payload into NVRAM' sector 1) at the factory, just a little 2kb ROM section I wasn't even aware of, till today.

The device boots, CPU is fine. Screen just shows big fat horizontal lines. TX/RX/keyboard don't work, neither audio. Trying to read display framebuffer shows garbage. EEPROM, bootloader, main FW area are fine. Result is exactly the same with several genuine or modded FW I tried. Even FF'd EEPROM.

So I don't have my own backup, but fortunately there is one in this repo. I own a generic ST-Link and have a basic knowledge about SWD unbricking.

If any of you successfully recovered from such a case, please let me know. NVR is only 4*512byte sectors to reflash :)

EDIT: Just used the RAM reader mod to dump NVR area : It is in fact exactly the same as the repo's dump (which was in fact a ROM section for the CPU). My assumption about me fucking up the area with cmd 0x0516 was ~false~ TRUE.

SO.... What the issue with mine? Have you ever encountered such a failure?

[Lar-Sen]

Some news. Getting a clue about what could be the origin of this issue, and discovered that 0x0516 "bootloader" command allows to push a 104 bytes binary chunk in device's RAM and flash it somewhere without any check. I don't have a clue about the use of that, but it could explain how I crashed my device.

So, playing with this command I may have suggested the CPU to flash garbage, possibly impacting bootloader or any other critical region I don't know. After a bit more investigation, the main problem is that CPU cannot get a read from internal ADC. Consequently, device is always in "extreme low" battery mode, even preventing it from booting.

Quick patches later I recovered some functionality, but screen keeps near unreadable, flickers heavily with strong lines, hangs if powersave is on, and of course, no correct battery reading. I simply faked it to permanently display 4 bars and patching other functions, effectively preventing "battery low" actions as a temporary measure :) It can TX again.

I don't know if simply playing with CPU instructions could physically break something inside. Maybe it's just my bad luck! Anyway, the last piece of code I still haven't checked for integrity is bootloader. I'll try to reflash it via SWD.

Do you think a corrupted bootloader could affect internal peripherals that way? ...sorry for being so chatty! anyway diagnosing it is still fun there :)

[Lar-Sen]

Final thoughts

This time I got it right :) While I was playing with 0x516 UART command, I innocently sent data which triggered a sort of conterfeiting protection built-in the factory firmware. Their scheme effectively blocks ADC functionality, displays several big horizontal lines (pattern 0xF0 to display), and prevents any further boot of the transceiver. As I'm not so familiar with embedded development, this is a real discovery to me. I'm aware about the heavy counterfeiting activity in China, but I wasn't supposed to get such a protection scheme in a $12 product :D

Nice job, Quansheng! As in the meantime, I was so close to declare my UVK5 as dead, that I ordered a new one... For nothing. Some patches later, removing all the nasty things, it cames back in action for good!

tl;dr : Don't play with UART 0x516 command. It is for factory reserved use. It aims to set a digital signature -involving unique "CPU Id" and QS keys- ~into a hidden area of the CPU~ to the 3rd NVRAM block, to prevent counterfeiting. If ever, I'm actually cooking a mod to disable and remove all the nasty bits.

[0ryn]

I've done something similar to mine. I used k5prog but gave it a firmware file to load to the eeprom. My radio thinks the battery is at 0.27% 0v and won't turn on. I can turn it on by pressing a key a power on. I can flash new firmware and also have dumped the eeprom from another radio using k5prog and tried to write it to broken radio. How exactly did you fix yours?

[Lar-Sen]

Interesting case. It is a different issue anyway. Considering wrong battery calibration data which now resides in yout eeprom, your HT "thinks" battery is really really flat and triggers "gReducedService" (as named here: https://github.com/Lar-Sen/uv-k5-firmware/blob/main/main.c ) But even in my (more severe) case, I was still able to reprogram EEPROM using cable and a blind restore tool. I think k5prog should do the trick, or even k5prog-win alternative if you're using windows: https://github.com/OneOfEleven/k5prog-win/blob/main/k5prog_win.exe

Personally I prefer restoring EEPROM dump using python:

https://github.com/Lar-Sen/Quansheng_UV-K5_Kitchen/blob/main/v2.01.31_mods/utils/eeprom_tool.py Don't forget to import updated libuvk5.py: https://github.com/Lar-Sen/Quansheng_UV-K5_Kitchen/blob/main/v2.01.31_mods/utils/libuvk5.py

In rare cases, a wrong EEPROM may set a custom AES key, which would prevent you from restoring any parameter. In that case, I suggest you to fully wipe AES keys using below tool, as it uses a backdoor key to restore EEPROM access: https://github.com/Lar-Sen/Quansheng_UV-K5_Kitchen/blob/main/v2.01.31_mods/utils/cmd052D_authenticate.py

cmd052D_authenticate.py <interface> unlock

Trust me, these units are nearly impossible to brick :)

Edit: As you probably lost your original EEPROM, make sure you rely on a good dump to restore. Here is one https://github.com/amnemonic/Quansheng_UV-K5_Firmware/blob/main/firmware/raws/uvk5(8)_eeprom_dump.bin

[0ryn]

Nice, that totally worked. Luckily I read the readme before flashing and created a backup of the original eeprom. I then used k5prog -Y -B k5__backup_eeprom.raw

Now it shows the correct battery voltage on boot. It does appear that giving k5prog a larger file than it wanted causes it to write to places that it shouldn't. It does say use with caution. I was considering opening up the radio, removing the eeprom and flashing it externally. I'm glad I didn't have to after watching some poor dude on YT crack the LCD squeezing the case back together.

Many thanks :)

[sq5bpf]

Nice, that totally worked. Luckily I read the readme before flashing and created a backup of the original eeprom. I then used k5prog -Y -B k5__backup_eeprom.raw

Thanks for reading the documentation and creating the backup first :)

For others reading this: you can also use the image read from the radio by chirp, just cut it to the first 8192 bytes. I made the chirp driver read all eeprom by design so that people would have backups laying around.

Now it shows the correct battery voltage on boot. It does appear that giving k5prog a larger file than it wanted causes it to write to places that it shouldn't. It does say use with caution.

Which option did you use when you bricked the radio? -W or -B ?

-W write most of the eeprom (but without what i think is calibration data) -B write ALL of the eeprom (the "brick my radio" mode)

-W should be safe, and should NOT write to places it shouldn't For -B there is a valid reason you have to pass the "i know what i'm doing" option :)

[0ryn]

Interestingly I used -w but with the firmware instead of the eeprom backup. I'm not sure if this is what broke things. I flashed uv-k5-firmware-fagci-mod-spectrum-reborn-31-12-2023.bin which gives you no backlight and did the hold down Exit(D) on power on - which fixes the backlight. I discovered that I wasn't able to restore my presets using chirp. I flashed egzumer and when I turned off the radio it didn't turn back on again :(

I was able to use the factory tool in windows to put the original firmware back which does turn on even with the battery voltage saying 0.12V 0% and it's usable. I then (thinking that the factory firmware had fixed things) flash back egzumer, which worked directly after the flash, but it failed after a power cycle.

If anyone else has this problem and wants to flash the eeprom, you can get an egzumer radio to power on by holding any key down whilst powering up, you'll get a release key message, but you can then use k5prog in that state.

After reading the advice here I tried with -W (which failed) and -B which worked. I'm still very new to these radios and trying to get back to using the ham license that I got when I was 14 years old (I'm 52 now) [G1ZXC] if anyone is interested.