another lesson is it's key to have a decent check method in place, for MKS they simply used RSA128 code to act as a form of crc but they made a mistake in the code in that it erased first, then checked the incoming packets for correct rsa sequence decrypt and if they passed were written, if failed it would error out but has already started the erase procedure rendering the device bricked.
While most of my loaders work with sd-card/usb flash/uart over usb there are much more modern ones like the new st example which make the device appear as a flash card and you just drag and drop a bin file(a check is implemented that the first few bytes point into a proper vector table or it wont write), or the older DFU version (buggy as heck even in silicon based DFU) The main thing i have learned in all this re-writing bootloaders is it's key to allow bootloader activation even if firmware corrupts, one device i have always goes to bootloader if powered via USB yet it was not implemented ,it was there in the code but it was skipped by a prior instruction, bug or left test code i dont know but once i NOP'ed out that it allowed me to write correct firmware and it lived again. You will also find it hard to do the A/B flash space on many stm's you look at, even though I have implemented such myself on stm's and others I have found it works best on spi flash based devices offering more /swappable memory space. Most implement a bootloader in it's own right with app being compiled ass separate entity, here is a example it for stm32f407 but the main code principle is the same for most stm, it looks for a bin file on sd-card and writes it to flash and then resets into it, (that just mean i load the vector table into ram and the reset into the new vector table) or this one which has more complicated setup, this one runs a small crc check as it reads the data, if crc fails it wont write, if it passes it's decrypted then written (it's open sources version of the nasty and stupid encrypted MKS robin bootloader ) I have many more code examples of bootloaders and apps in platformio / stm32cube base if needed, you will note most have a encrypt/decrypt option as i've found the need to hack quite a few badly done bootloaders in order to repair the device which has since bricked and more care was put into encrypting the IP than ensuring correct updates. JTAG cable for connection to a standard JTAG 20-pin 2.As a user who has fallen prey to badly implemented bootloaders with little to no fail safe's, I can say its not a fun rabbit hole to go down.1.65 V to 3.6 V application voltage support on the JTAG/SWD interface and 5 V tolerant inputs.JTAG/serial wire debug (SWD) specific features:.SWIM cable for connection to an application with pin headers or 2.54 mm pitch connector.
SWIM cable for connection to an application with an ERNI standard connector Vertical connector reference: 284697 or 214017 Horizontal connector reference: 214012.SWIM programming speed rates: 9.7 kbyte/s in low-speed, 12.8 kbyte/s in high-speed.