Getting it off is relatively easy: Soldering iron with fine tip and an exacto-knife. Heat legs and use knife to bend them up. Or a fine piece of bus-wire from the back to lift them as you go.
Putting it back on can be done with the glob & wick method:
Iâve ordered a new chip from Mouser. What gripes me is that the company
sells replacement boards, $100 with $48 shipping from China. Geeze. Last
I checked, shipping from china was basically free for small stuff like that
thanks to the US Post Office and China Post special deal which basically
killed the US home business sector. But thatâs another discussion.
I just thought of something. Maybe a bit of a road block.
Typically a 3d Printer manufacturer would send out a firmware update that you load with their loader tool. This puts the micro into a BOOT0 condition to execute the firmware in the system memory, which has the only job of receiving the hex dump which it then writes to the user space, and resets, launching into the user space code. This is what I experienced with another project (Cricut cutter). I have the suspicion that since I have a .hex file not a .bin file which is what I usually get from mbed (for my arm projects) when I compile something, there may be another element to this problem that I hadnât originally thought of. I still havenât gotten that chip. Must have been sent on the slow boat.
The main difference between a .bin and a .hex is a .hex has all of the location information embedded in it. You can update many regions of memory at the same time, or put data in one random region.
.bin files do not include location information, so you need to provide a base address (or have a bootloder that is coordinated with the compilation settings) so that itâs placed in the right location. Itâs just a stream of binary data that gets written from that base address forward.
Translation: .bin is the raw data to put into memory (Flash, EPROM, OTP ROM, etcâŚ), .hex needs cleaning up and translating into the raw data. You canât just place it into memory.