Solution to problems that jlink cannot be used after jlink is updated to v4.65d

In the past few days, we have been using the MCU of 2017f050c6d for porting and development. Only the latest version supports this MCU, so we are forced to update it to the latest version. Mdk4.6 and jlin4.56d have been shared in my resources. After the installation, an update is prompted. After the update, the jlink is notified that the jlink is clone.

The solution is as follows:

1. Re-burn the firmware to jlink, enable the original v8.bin firmware with winhex, and find the 4bytes address with the offset of 0xff00 and change it to another value, as long as it is not the original 11111117 or 805306163, because the updated firmware performs force verification on the two firmware SNS and changes it to another value, the problem can be solved perfectly, at the same time, change the gdbfull after 0xff30 to gdbfull, and the corresponding ASCII code is 47.
44 42 46 55 4C, aims to skip the gdbfull check.

1.1 another flexible method to modify the SN: Change 0xff00 as the 4bytes of the starting address to 0 xffffffff, and change gdbfull after 0xff30 to gdbfull, the corresponding ASCII code is 47 44 42 46 55 4C, which aims to skip the gdbfull check and save the modified firmware file. After the firmware is updated, enable commander and ignore the update. After the jlink command, enter

Exec setsn = XXXXXXXX. The entered Sn is in hexadecimal format. Otherwise, an error occurs during update and upgrade. We recommend that you define the update time, such as 20121121, so that you can trace the last time of the firmware.

2. At this time, the segger4.65d version is installed. Open jlink commander and follow the prompts to update it. After the update, you can use the latest version normally.

PS: After cm0 is added with read protection, segger's unsecured chip function cannot be used normally and no solution has been found. After contacting ST's Fae, we recommend that you use stvp of St link to erase option byte and RDP.

After the firmware is updated, the actual test shows that it is easier to drop the firmware. The previous firmware is not used once every six months on the same hardware platform. After the update, it is estimated that the firmware will be dropped on average in half a month. The problem is not found yet. In this case, the reasoning is only related to the firmware. Or is there any change in the hardware operation caused by the new firmware?

Note:At the same time, modify gdbfull to gdbfull or other characters. According to the actual test, the firmware cannot be removed for one month. Therefore, except for the SN, you must modify the gdbfull character. Solve the problem that firmware is often removed after only Sn is modified.