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.

[eXisten]

Thanks. egzumer firmware has version started from *, but bootloader still don't accept it.

Where does this "*" come from?

[radiolistener]

Where does this "*" come from?

from version string. It is packed with firmware image.

When you do firmware unpack this version string is displayed here:

Code: [Select]

$ ./k5tool -unpack RT590_v2.01.32_publish.bin
CRC check passed...
   Version: 2.01.32
When you do firmware pack, you're needs to provide that version string

[radiolistener]

I've given it a go, but no luck. Here's the log attached.

Do you use classic UV-K5 model, or some clone?

[Chris79]

It's one of the new Quansheng UV-5R Plus models. Looks a little like a Baofeng, but system is Quansheng
*Also has a usb charging port, which the original Quansheng UV-5R Plus models didn't have.

[eXisten]

I have an identical one! Mine also has a USB charging port (which wasn't there before)
Well, we just have to wait until someone comes up with something.

[Chris79]

Just for comparison, I ordered and have just received another UV-5R Plus from Ali Express at the grand total of £4.37 delivered.
This time, I received one of the non-USB ones.

Here are side by side photos, the usb one (with newer firmware) on the left in each photo. (I've erased the serial numbers from the photos).

There is a distinct difference with the smaller connector (mic input?) on the newer model, which is different from all other uv-K5 radios. I also noticed that the usb one shows a "usb connected" icon (2 pin plug) on screen too when the flashing cable is attached and the radio switched on, which the non-usb doesn't, which maybe suggests something is physically different with how the usb port is wired up?

This one flashed fine, as expected.

There is reference to a USB and non-USB radio in the manual too.

[ftg]

I can as well confirm that the Quansheng UV-5R Plus with USB-C charging has version 5 firmware and bootloader.

There has been some preliminiary reversing by tunas1337 that points towards at least the firmware upload commands being changed.

The firmware was graciously dumped by UB4C and is also attached below.
It is also mirrored here:
https://prkele.prk.tky.fi/~ftg/images/uvk5/qz_uv-5r_plus_ver5fw/fw_dump_from_UB4C/

If any of you want something tested on the physical hardware, do let me know.

[radiolistener]

There has been some preliminiary reversing by tunas1337 that points towards at least the firmware upload commands being changed.

The firmware was graciously dumped by UB4C and is also attached below.
It is also mirrored here:
https://prkele.prk.tky.fi/~ftg/images/uvk5/qz_uv-5r_plus_ver5fw/fw_dump_from_UB4C/

Thanks a lot.
At a glance, not only upload command is changed, but also responses.
Do you have the same dump for an old bootloader 2.00.06?
It will helps to reverse.

[radiolistener]

Some findings. The new bootloader supports 3 commands:

Code: [Select]

$ arm-none-eabi-objdump -D -b binary -marm --start-address=0x27c --stop-address=0x2a8 -Mforce-thumb bootloader.bin

     27c: b510      push {r4, lr}
     27e: 4809      ldr r0, [pc, #36] @ (0x2a4)       @ r0 = 0x20000B24; // packet_ptr = pointer to unpacked packet
     280: 22af      movs r2, #175 @ 0xaf          @ r2 = 0x00af
     282: 8801      ldrh r1, [r0, #0]                @ r1 = *(short*)&packet_ptr[0]; // packet id
     284: 00d2      lsls r2, r2, #3                  @ r2 = r2 << 3 = 0x0578;
     286: 1a89      subs r1, r1, r2                  @ r1 = r1-r2;
     288: d006      beq.n 0x298                       @ [if (r1==0x0578) { call 0x30c; return; }]
     28a: 2903      cmp r1, #3
     28c: d007      beq.n 0x29e                       @ [if (r1==0x057b) { call 0x338; return; }]
     28e: 2905      cmp r1, #5
     290: d101      bne.n 0x296                       @ [if (r1==0x057d) { call 0x2a8; return; }]
     292: f000 f809 bl 0x2a8                           
     296: bd10      pop {r4, pc}                       
     298: f000 f838 bl 0x30c
     29c: bd10      pop {r4, pc}
     29e: f000 f84b bl 0x338
     2a2: bd10      pop {r4, pc}
     2a4: 0b24      lsrs r4, r4, #12
     2a6: 2000      movs r0, #0

It seems that the new packet id=0x057d is a new flash unlock command it is processed with procedure at address 0x2a8.

This procedure checks if a first letter of version string is '*' or equals to the first letter of bootloader version string "5.00.01" (0x0bf0 offset) and ignores packet if it don't equals:

Code: [Select]

$ arm-none-eabi-objdump -D -b binary -marm --start-address=0x2a8 --stop-address=0x30c -Mforce-thumb bootloader.bin

     2a8: b510      push {r4, lr}
     2aa: 7d01      ldrb r1, [r0, #20]               @ r1 = (byte)packet_ptr[20];
     2ac: b08c      sub sp, #48 @ 0x30                  @ sp -= 48;     // alloc 48 bytes on stack
     2ae: 2910      cmp r1, #16
     2b0: d224      bcs.n 0x2fc                       @ if (r1 >= 16) return;
     2b2: 4a13      ldr r2, [pc, #76] @ (0x300)       @ r2 = 0x0BF0;                  // pointer to string "5.00.01"
     2b4: 7900      ldrb r0, [r0, #4]                @ r0 = (byte)packet_ptr[4];  // first letter of version string
     2b6: 7812      ldrb r2, [r2, #0]                @ r2 = '5';
     2b8: 4290      cmp r0, r2
     2ba: d001      beq.n 0x2c0
     2bc: 282a      cmp r0, #42 @ 0x2a
     2be: d11d      bne.n 0x2fc                       @ if (r0!=r2 && r0!='*') return;
     2c0: 4a10      ldr r2, [pc, #64] @ (0x304)       @ r2 = 0x20000314;  // ptrVars
     2c2: 2001      movs r0, #1                      @ r0 = 1;
     2c4: 7050      strb r0, [r2, #1]                @ r2[1] = (byte)r0; // IsWriteEnable = 1;
     2c6: 4810      ldr r0, [pc, #64] @ (0x308)       @ r0 = 0x09f0;      // ptr to bootloader area at 0x09f0 offset
     2c8: 0149      lsls r1, r1, #5                  @ r1 = r1 << 5;
     2ca: 1809      adds r1, r1, r0                  @ r1 += r0;         // r1 = (byte)packet_ptr[20] * 0x20 + 0x09f0;
     2cc: 460c      mov r4, r1                          @ r4 = r1;
     2ce: 2210      movs r2, #16                     @ r2 = 16;
     2d0: a804      add r0, sp, #16                     @ r0 = sp+16;
     2d2: f7ff ff3f bl 0x154                           @ call 0x154; // memcpy(r0, r1, r2);
     2d6: 4621      mov r1, r4                          @ r1 = r4;
     2d8: 3110      adds r1, #16                     @ r1 += 16;
     2da: 2210      movs r2, #16                     @ r2 = 16;
     2dc: 4668      mov r0, sp                          @ r0 = sp;
     2de: f7ff ff39 bl 0x154                           @ call 0x154; // memcpy(r0, r1, r2);
     2e2: 466a      mov r2, sp                          @ r2 = sp;
     2e4: a904      add r1, sp, #16                     @ r1 = sp+16;
     2e6: 2001      movs r0, #1                      @ r0 = 1;
     2e8: f000 f902 bl 0x4f0                           @ call 0x4f0;
     2ec: a808      add r0, sp, #32                     @ r0 = sp+32;
     2ee: f7ff ffb1 bl 0x254                           @ call 0x254;
     2f2: 466a      mov r2, sp                          @ r2 = sp;
     2f4: a908      add r1, sp, #32                     @ r1 = sp+32;
     2f6: 2002      movs r0, #2                      @ r0 = 2;
     2f8: f000 f8fa bl 0x4f0                           @ call 0x4f0
     2fc: b00c      add sp, #48 @ 0x30                  @ sp += 48;     // free 48 bytes on stack
     2fe: bd10      pop {r4, pc}                        @ return;
     300: 0bf0      lsrs r0, r6, #15
     302: 0000      movs r0, r0
     304: 0314      lsls r4, r2, #12
     306: 2000      movs r0, #0
     308: 09f0      lsrs r0, r6, #7
     30a: 0000      movs r0, r0     

But there is a new unknown byte field after 16 bytes of version string signature. The procedure rejects packet if this byte is >= 0x10. If this field is less than 0x10, then it calculates ptr = byte * 0x20 + 0x09F0. It appears like pointer to bootloader area which starts at 0x09f0 offset. Then it doing some manipulation with it. Needs time to discover it more deep...

Let me know if you discover more details.

[radiolistener]

The new write flash packet has id=0x057b.
The procedure which process this packet starts at 0x0338 offset, it get argument packet_ptr passed through r0.

Code: [Select]

arm-none-eabi-objdump -D -b binary -marm --start-address=0x338 --stop-address=0x464 -Mforce-thumb bootloader.bin

     338: b5f8      push {r3, r4, r5, r6, r7, lr}
     33a: 4c46      ldr r4, [pc, #280] @ (0x454)      @ r4 = 0x20000314
     33c: 4605      mov r5, r0                        @ r5 = packet_ptr
     33e: 7860      ldrb r0, [r4, #1]                  @ r0 = (byte)r4[1];   // r0=IsWriteEnabled;
     340: 2801      cmp r0, #1
     342: d005      beq.n 0x350                    @ if (!IsWriteEnabled) { call_0480(0, 1, 0); return; }
     344: 2100      movs r1, #0
     346: 2201      movs r2, #1
     348: 4608      mov r0, r1
     34a: f000 f899 bl 0x480
     34e: bdf8      pop {r3, r4, r5, r6, r7, pc}
     350: 7a68      ldrb r0, [r5, #9]                  @ r0 = (byte)packet_ptr[9];     // r0=chunkNumber.hi;
     352: 7a29      ldrb r1, [r5, #8]                  @ r1 = (byte)packet_ptr[8];     // r1=chunkNumber.lo;
     354: 0200      lsls r0, r0, #8                    @ r0 <<= 8;
     356: 4308      orrs r0, r1                        @ r0 |= r1;    // r0 = chunkNumber;
     358: d01c      beq.n 0x394                    @ if (r0 != 0) goto 0x394;
     35a: 7820      ldrb r0, [r4, #0]                  @    r0 = (byte)r4[0]; // some variable
     35c: 2802      cmp r0, #2
     35e: d1f6      bne.n 0x34e
     360: 483d      ldr r0, [pc, #244] @ (0x458)
     362: 6801      ldr r1, [r0, #0]
     364: 2208      movs r2, #8
     366: 4051      eors r1, r2
     368: 6001      str r1, [r0, #0]
     36a: 7a68      ldrb r0, [r5, #9]
     36c: 7a29      ldrb r1, [r5, #8]
     36e: 0200      lsls r0, r0, #8
     370: 4308      orrs r0, r1
     372: 8861      ldrh r1, [r4, #2]
     374: 1c49      adds r1, r1, #1
     376: 4288      cmp r0, r1
     378: d105      bne.n 0x386
     37a: 1d28      adds r0, r5, #4
     37c: f7ff ff0e bl 0x19c
     380: 68a1      ldr r1, [r4, #8]
     382: 4288      cmp r0, r1
     384: d021      beq.n 0x3ca
     386: 2100      movs r1, #0
     388: 2201      movs r2, #1
     38a: 4608      mov r0, r1
     38c: f000 f878 bl 0x480
     390: 2001      movs r0, #1
     392: e05d      b.n 0x450
     394: 1d28      adds r0, r5, #4
     396: f7ff ff01 bl 0x19c
     39a: 60a0      str r0, [r4, #8]
     39c: 7ae8      ldrb r0, [r5, #11]
     39e: 7aa9      ldrb r1, [r5, #10]
     3a0: 0200      lsls r0, r0, #8
     3a2: 4308      orrs r0, r1
     3a4: 80a0      strh r0, [r4, #4]
     3a6: 2000      movs r0, #0
     3a8: 8060      strh r0, [r4, #2]
     3aa: 2002      movs r0, #2
     3ac: 7020      strb r0, [r4, #0]
     3ae: 2778      movs r7, #120 @ 0x78
     3b0: b672      cpsid i
     3b2: 2600      movs r6, #0
     3b4: 2001      movs r0, #1
     3b6: 0271      lsls r1, r6, #9
     3b8: 0300      lsls r0, r0, #12
     3ba: 1808      adds r0, r1, r0
     3bc: f7ff ff10 bl 0x1e0
     3c0: 1c76      adds r6, r6, #1
     3c2: b2b6      uxth r6, r6
     3c4: 42be      cmp r6, r7
     3c6: d3f5      bcc.n 0x3b4
     3c8: b662      cpsie i
     3ca: 22ff      movs r2, #255 @ 0xff
     3cc: 4629      mov r1, r5
     3ce: 3201      adds r2, #1
     3d0: 3110      adds r1, #16
     3d2: 4822      ldr r0, [pc, #136] @ (0x45c)
     3d4: f7ff febe bl 0x154
     3d8: 4920      ldr r1, [pc, #128] @ (0x45c)
     3da: 2000      movs r0, #0
     3dc: 0082      lsls r2, r0, #2
     3de: 588b      ldr r3, [r1, r2]
     3e0: 1c40      adds r0, r0, #1
     3e2: ba1b      rev r3, r3
     3e4: b280      uxth r0, r0
     3e6: 508b      str r3, [r1, r2]
     3e8: 2840      cmp r0, #64 @ 0x40
     3ea: d3f7      bcc.n 0x3dc
     3ec: 4f1c      ldr r7, [pc, #112] @ (0x460)
     3ee: 2600      movs r6, #0
     3f0: 0130      lsls r0, r6, #4
     3f2: 4a1a      ldr r2, [pc, #104] @ (0x45c)
     3f4: 19c1      adds r1, r0, r7
     3f6: 1880      adds r0, r0, r2
     3f8: f7ff ff10 bl 0x21c
     3fc: 1c76      adds r6, r6, #1
     3fe: b2b6      uxth r6, r6
     400: 2e10      cmp r6, #16
     402: d3f5      bcc.n 0x3f0
     404: 2000      movs r0, #0
     406: 0082      lsls r2, r0, #2
     408: 58b9      ldr r1, [r7, r2]
     40a: 1c40      adds r0, r0, #1
     40c: ba09      rev r1, r1
     40e: b280      uxth r0, r0
     410: 50b9      str r1, [r7, r2]
     412: 2840      cmp r0, #64 @ 0x40
     414: d3f7      bcc.n 0x406
     416: b672      cpsid i
     418: 7a68      ldrb r0, [r5, #9]
     41a: 7a29      ldrb r1, [r5, #8]
     41c: 0200      lsls r0, r0, #8
     41e: 4308      orrs r0, r1
     420: 0201      lsls r1, r0, #8
     422: 2001      movs r0, #1
     424: 0300      lsls r0, r0, #12
     426: 1808      adds r0, r1, r0
     428: 2240      movs r2, #64 @ 0x40
     42a: 490d      ldr r1, [pc, #52] @ (0x460)
     42c: f7ff fede bl 0x1ec
     430: b662      cpsie i
     432: 7a68      ldrb r0, [r5, #9]
     434: 7a2a      ldrb r2, [r5, #8]
     436: 0201      lsls r1, r0, #8
     438: 4311      orrs r1, r2
     43a: 8061      strh r1, [r4, #2]
     43c: 2200      movs r2, #0
     43e: 68a0      ldr r0, [r4, #8]
     440: f000 f81e bl 0x480
     444: 8860      ldrh r0, [r4, #2]
     446: 88a1      ldrh r1, [r4, #4]
     448: 1c40      adds r0, r0, #1
     44a: 4288      cmp r0, r1
     44c: d187      bne.n 0x35e
     44e: 2003      movs r0, #3
     450: 7020      strb r0, [r4, #0]
     452: bdf8      pop {r3, r4, r5, r6, r7, pc}
     454: 0314      lsls r4, r2, #12
     456: 2000      movs r0, #0
     458: 1000      asrs r0, r0, #32
     45a: 4006      ands r6, r0
     45c: 1124      asrs r4, r4, #4
     45e: 2000      movs r0, #0
     460: 0f24      lsrs r4, r4, #28
     462: 2000      movs r0, #0

Preliminary structure looks the same as for old packet 0x0519. But needs more detailed check.

It looks like the only thing that needs to be changed for bootloader v5 is just to replace packet id for version packet 0x057d (instead of 0x0530) and for write packet 0x057b (instead of 0x0519) and add byte field at the end of version packet. The meaning of this field still unclear, but it should be < 0x10.

Also it looks that the new write packet 0x057b possible uses some kind of firmware decryption, see this code:

Code: [Select]

     3ca: 22ff      movs r2, #255 @ 0xff              @    r2 = 255;
     3cc: 4629      mov r1, r5                        @    r1 = r5;
     3ce: 3201      adds r2, #1                        @    r2 += 1;
     3d0: 3110      adds r1, #16                       @    r1 += 16;
     3d2: 4822      ldr r0, [pc, #136] @ (0x45c)      @    r0 = 0x20001124;
     3d4: f7ff febe bl 0x154                         @    memcpy(r0, r1, r2);
     3d8: 4920      ldr r1, [pc, #128] @ (0x45c)      @    r1 = 0x20001124;
     3da: 2000      movs r0, #0                        @    r0 = 0;
     3dc: 0082      lsls r2, r0, #2                    @    r2 = r0 << 2;
     3de: 588b      ldr r3, [r1, r2]                  @    r3 = *(uint32_t)(r1+r2);
     3e0: 1c40      adds r0, r0, #1                    @    r0 += 1;
     3e2: ba1b      rev r3, r3
     3e4: b280      uxth r0, r0
     3e6: 508b      str r3, [r1, r2]
     3e8: 2840      cmp r0, #64 @ 0x40
     3ea: d3f7      bcc.n 0x3dc
     3ec: 4f1c      ldr r7, [pc, #112] @ (0x460)
     3ee: 2600      movs r6, #0
     3f0: 0130      lsls r0, r6, #4
     3f2: 4a1a      ldr r2, [pc, #104] @ (0x45c)
     3f4: 19c1      adds r1, r0, r7
     3f6: 1880      adds r0, r0, r2
     3f8: f7ff ff10 bl 0x21c
     3fc: 1c76      adds r6, r6, #1
     3fe: b2b6      uxth r6, r6
     400: 2e10      cmp r6, #16
     402: d3f5      bcc.n 0x3f0
     404: 2000      movs r0, #0
     406: 0082      lsls r2, r0, #2
     408: 58b9      ldr r1, [r7, r2]
     40a: 1c40      adds r0, r0, #1
     40c: ba09      rev r1, r1
     40e: b280      uxth r0, r0
     410: 50b9      str r1, [r7, r2]
     412: 2840      cmp r0, #64 @ 0x40
     414: d3f7      bcc.n 0x406

I'm not sure what is going on here, needs to analyze it more deep.

PS: this is my first experience with ARM assembly code analysis, so it's not easy to read it, because I'm used to assembler of other processors. ARM assembly code looks like an explosion in a pasta factory 

[radiolistener]

The response for write flash packet for bootloader 5 is exactly the same as for bootloader 2.
The only difference is id=0x057c (instead of 0x051a). The structure is exactly the same:

Code: [Select]

$ arm-none-eabi-objdump -D -b binary -marm --start-address=0x480 --stop-address=0x4a1 -Mforce-thumb bootloader.bin

@ SendPacket_057c([r0]uint32_t sequenceId, [r1]uint16_t chunkNumber, [r2]uint8_t errorCode)
     480: b53e      push {r1, r2, r3, r4, r5, lr}
     482: 4c06      ldr r4, [pc, #24] @ (0x49c)      @ r4 = 0x057C;
     484: 466b      mov r3, sp                        @ r3 = sp;
     486: 801c      strh r4, [r3, #0]                  @ r3[0] = (uint16_t)r4;
     488: 2408      movs r4, #8
     48a: 805c      strh r4, [r3, #2]                  @ r3[2] = (uint16_t)8;
     48c: 9001      str r0, [sp, #4]                  @ sp[4] = (uint32_t)sequenceId;
     48e: 8119      strh r1, [r3, #8]                  @ r3[8] = (uint16_t)chunkNumber;
     490: 729a      strb r2, [r3, #10]                 @ r3[10] = (uint8_t)errorCode;
     492: 210c      movs r1, #12
     494: 4668      mov r0, sp
     496: f000 f9cf bl 0x838                         @ SendPacket(sp, 12);
     49a: bd3e      pop {r1, r2, r3, r4, r5, pc}      @ return;
     49c: 057c      lsls r4, r7, #21
     49e: 0000      movs r0, r0