I have been attempting to extract the firmware from an HVAC controller board using my Pickit3 and MPLAB X.
It seems that many HVAC controllers are PIC based and most are kind enough to include debug/flash pins. Grabbing the firmware images should be trivial once the correct pins are traced out. MPLAB X will see my Pickit3 and the target MCU, but it fails to pull an image that isn’t all zeros. (The “bin” file is a text file with each line noting the start address, followed by 16 byte values.)
I do get an occasional “Target device ID invalid message” but that is usually due to my janky wiring to the board. Once I get that issue cleared, MPLAB will always warn that the debug bit (byte?) is set on the MCU. (That doesn’t make sense as the MCU should be running standalone on the board during normal operation.)
Is there some kind of read protection that may be enabled on the PIC? Do I just need to unsolder the PIC and put it in its own dedicated circuit for pulling the firmware?
Is there some kind of read protection that may be enabled on the PIC? Do I just need to unsolder the PIC and put it in its own dedicated circuit for pulling the firmware?
There are protections on Atmel chips (aka AVRs) made by the same company (Microchip).
Do you have a more specific part number? PIC16F is a large family of chips.
Can you identify the parts involved and get their data sheets? Are you sure the device is responding to whatever you are doing to query its firmware?
Do you have access to a scope to monitor the wires used for whatever interface is used for communication? It could be that the device is simply outputting all zeroes, and MPLAB doesn’t know what to make of it. Maybe they are pulling the output pin to ground through an external resistor to protect from nosy customers and depopulate that when doing their own debugging.
Just a few thoughts, I havent messed around with these but have debugged a fair share of embedded things.
