search

amnemonic / Quansheng_UV-K5_Firmware

Quansheng UV-K5 Firmware
681 stars 128 forks source link

Abnormalities After Replacing the MCU #137

Open losehu opened 1 month ago

losehu commented 1 month ago

After I replaced the MCU in my K5 and flashed the Quansheng bootloader and firmware, I found that the screen displayed stripes upon startup and the device became unusable. I am quite puzzled by this. Could it be that there is encryption in the bootloader targeting specific MCUs?

I have confirmed that both the bootloader and firmware are from Quansheng, and they worked perfectly fine before I replaced the MCU. I purchased the MCU from the official DP32G030 store.

What's even more puzzling is that when I flashed third-party firmware, the device was able to boot and function, but there were still some anomalies. For example, the battery level starts at 0 upon booting and gradually increases to the normal level.

The image shows the startup screen when using Quansheng's bootloader and firmware, while the video demonstrates the battery level anomaly caused by using third-party firmware.

IMG_1793

https://github.com/user-attachments/assets/f329d406-5375-4661-832d-8dbce892a505

If you have any suggestions, I would greatly appreciate them！

losehu commented 1 month ago

IMG_1794 https://m.tb.cn/h.gl2EaRTow3WnVsB?tk=4b6T3eUIjfB

this is my new MCU

losehu commented 1 month ago

When I use the DualTachyon firmware, the device operates normally without the startup screen glitch.

amnemonic commented 1 month ago

It is most probably caused by counterfeit algorithm and involving QS digital signautre stored in NVRAM. Read more about it here: https://github.com/amnemonic/Quansheng_UV-K5_Firmware/issues/107#issuecomment-1832333082

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.

losehu commented 1 month ago

To address the issue of black and white horizontal stripes on the screen, I reverse-engineered the Quansheng firmware and set 0x170A to 1(in pictures) ,which ensures that the checksum always returns true. However, I still have new issues:

After I replaced the MCU in my K5 and flashed the Quansheng bootloader and firmware, I found that the screen displayed stripes upon startup and the device became unusable. I am quite puzzled by this. Could it be that there is encryption in the bootloader targeting specific MCUs?

I have confirmed that both the bootloader and firmware are from Quansheng, and they worked perfectly fine before I replaced the MCU. I purchased the MCU from the official DP32G030 store.

What's even more puzzling is that when I flashed third-party firmware, the device was able to boot and function, but there were still some anomalies. For example, the battery level starts at 0 upon booting and gradually increases to the normal level.

The image shows the startup screen when using Quansheng's bootloader and firmware, while the video demonstrates the battery level anomaly caused by using third-party firmware.

I sincerely appreciate for ur suggestions！ camphoto_351212254 camphoto_1297389768

amnemonic commented 1 month ago

I'm not sure about other questions but regarding this one:

Why does the battery voltage reading become abnormal after I replace the MCU with a blank one and flash third-party firmware?

I think it also can be related to NVR as in translated datasheet we can read:

64KB FLASH is used as program storage area, with 2KB NVR area and 64KB MAIN area. The NVR area is mainly used to store some data specific to our company, such as factory code information, TRIM data, and product configuration information.

so probably ADC setting (which are used when measuring battery voltage) may be wrong when NVR isn't correct. To "properly" replace MCU and use stock firmware you would need to know what looks the factory test procedure and use UART command 0x0516 to write proper calibration data.

losehu commented 1 month ago

I received a demo program for the DP32G030, and I observed that there are operations related to reading from and writing to the NVR area into registers. Could this be related? b789e49f097068e307e305314f2a826f

Regarding the NVR data, I noticed in the datasheet that this should be pre-configured by the MCU manufacturer, not set by Quansheng. Is this correct? If so, why does Quansheng need to modify the NVR area?