Electrical and Computer Engineering

870 readers

2 users here now

Electrical and computer engineering (ECE) community, for professionals and learners. Discuss ECE related topics here, for instance digital design, signal processing, circuit analysis, electromagnetics, microelectronics, power electronics, RF electronics, etc.

founded 2 years ago

MODERATORS

[email protected]

Firmware extraction from PIC16F using MPLAB X and Pickit3; BIN is all zeros (lemmy.ca)

submitted 4 months ago by [email protected] to c/[email protected]

2 comments fedilink hide all child comments

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?

you are viewing a single comment's thread
view the rest of the comments

[–] [email protected] 1 points 4 months ago

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.