The dsPIC30F2010 was the first cheap way to put a dsPIC core on a motor drive: 28 pins, 12 KB of program flash, 512 bytes of SRAM, 1 KB of data EEPROM, a six-channel 10-bit converter, a three-phase PWM block and a quadrature encoder interface. It has been in pumps, fans, valve actuators and small inverters for two decades, and most of those boards have no source code left.
Twelve Kilobytes, One Thousand Twenty-Four Bytes
4,096 instruction words of 24 bits fill the array. On top of that sits a separate 1 KB EEPROM, which is the part of this device that most recovery requests actually need, because that is where the motor parameters live: pole pairs, encoder offset, current limit, ramp times, and often a serial number written at end of line.
Program flash and data EEPROM are different arrays with different read paths. A dump that stops at the end of the program array is technically a complete code recovery and practically useless, since a rebuilt drive with the wrong pole pair count runs backwards at the wrong speed. Any quote on this part should state whether the EEPROM is included, and any report should show it as a separate block rather than appended to the hex file without comment.
What The Motor Control Block Does
The PWM module produces three complementary pairs with programmable dead time, and the encoder interface counts quadrature edges without CPU help. Firmware built on this part is therefore mostly a control loop plus a fault layer, with the peripherals doing the timing.
That structure helps a read-out. Dead time, PWM frequency, ADC trigger point and current-limit threshold are all register values written during initialisation, in a short block of code near the reset vector. Reading that block tells you more about the drive than reading the control arithmetic, because it fixes the electrical envelope the firmware was designed for. Chip extraction analysis is where that annotation happens.
Protection Inside The 0xF80000 Block
Configuration registers, including the general segment protect setting, sit above the linear program array. On this family protection is segment-based: read and write restrictions on the general segment, rather than the rotated four-block scheme used by PIC18. The result on the bench is binary. Either the array reads, or it does not.
Three observations settle which case you have. The device ID at 0xFF0000 answers either way. The configuration registers read either way, and they tell you whether the watchdog was enabled and which oscillator mode was used. And the returned data either starts with a plausible GOTO at address zero or starts with zeros.
Erased And Protected Look Different Only If You Check
Erased 24-bit flash is 0xFFFFFF, so unused rows are obvious. Protected flash returns 0x000000, which is NOP, so a locked dump disassembles into a long stretch of no-ops that a hurried reviewer can mistake for padding.
The reset vector is the separating evidence. Real firmware cannot leave address zero as NOP, because after reset the core has to branch somewhere. A protected read leaves exactly that. When two independent sessions both return zeros from address zero while the device ID reads correctly, the part is locked and further electrical attempts will not change the answer.
Thermal And Mechanical Reality
28-pin SPDIP, SOIC or QFN. The SPDIP is the easy case: socket it and work in comfort. The QFN on a drive board with a ground plane is the hard one, and the controller usually shares a heatsink footprint with the power stage.
Where the array is reachable over ICSP, none of that matters. Where it is not, the decision to open the package should be taken with the replacement cost of the whole drive in view, not just the chip. Semi-invasive extraction is the standard route when the die has to be reached; our services page sets out what each level includes.
One more check is worth doing on a drive that still runs: read the configuration block and compare the PWM period and dead-time values with the motor nameplate. If they agree, the firmware belongs to that machine and the fault is outside the controller, which turns a recovery quote into a repair recommendation.
Verification
Two independent reads of both arrays compared word for word. A reset vector that initialises the PWM module before enabling outputs. A check that the EEPROM contents are self-consistent, since a half-written parameter block is common on boards that lost power during a save. And, where possible, a programming test into a blank part, because a drive that starts and immediately faults looks the same whether the code is wrong or the current sense is.
Send the full marking line, a photo of the board and the motor’s rating, then contact us and we will confirm whether the 1 KB EEPROM is readable on your revision before quoting. The dsPIC30F2011 is the 18-pin member of the same family, and it has no data EEPROM at all.