Production lines mix revisions, and they do it invisibly. A board built in March carries a dsPIC30F6014; the same board built in September carries a dsPIC30F6014A. The marking differs by one character, the firmware is nominally the same, and the converter behind it does not run at the same speed.
What The A Revision Changed
The non-A part samples at 100 ksps with twelve-bit resolution across sixteen channels. The A revision doubles the rate to 200 ksps. Memory, package, pinout and peripheral count are otherwise the same: 144 KB of flash, which is 48K instruction words ending at 0x017FFE, 8,192 bytes of SRAM, 4,096 bytes of EEPROM from 0x7FF000, two CAN controllers and a data converter interface for I2S and AC’97.
Doubling a conversion rate sounds like an improvement with no downside. In firmware terms it is a change of timing budget, and code written against the slower part often contains delays that assume a conversion takes twice as long as it now does.
Where The Timing Assumption Hides
A designer who needs the converter to settle before reading the result has three options: poll a done flag, wait a fixed number of cycles, or trigger the next conversion from hardware and read the previous result.
The first is revision-proof. The second is not. A loop that waits long enough for a 100 ksps conversion finishes early on the faster part, which is harmless, unless the wait was also serving as the settling time for an external amplifier or a multiplexer. Then it is a signal-integrity bug that appears only on the A revision.
The third is revision-proof in one direction and not the other: hardware-triggered conversion at 200 ksps on a part whose firmware assumes 100 ksps produces two results per expected one, and the sequencing logic reads stale and fresh data alternately.
None of this is visible in a hex comparison. It becomes visible when a machine built with one revision is repaired with the other.
Why It Matters For A Recovery
When a board arrives for a firmware read, the revision determines which datasheet governs the job and which errata apply. The A revision absorbed fixes that the non-A part carried as documented deviations, and some of those fixes changed peripheral behaviour in ways firmware can observe.
The practical consequence is that an image recovered from a non-A part may contain software workarounds for problems the A part does not have. They look like redundant code in disassembly and they are not. Removing them during a port reintroduces a fault the original designer already paid to solve.
The reverse is worse. An image written for the A revision, programmed into a non-A part, keeps the newer timing assumptions and loses the errata fixes.
Reading The Device ID First
The marking on an 80-pin TQFP is small and often illegible after years in a cabinet. The device ID at 0xFF0000 resolves it and normally answers even when the program array does not.
Read it before planning anything. Die and revision decide the datasheet, the errata and the expected converter rate, and two boards that look identical can differ here.
Configuration words at 0xF80000 come second. They record oscillator mode, watchdog enable, brown-out threshold and the code-protect setting. On industrial equipment, the oscillator choice decides whether a replacement board starts at all without its original crystal.
What The Firmware Uses The Extra Peripherals For
Two CAN controllers mean two bit-timing setups, two filter banks and two receive paths. Recovering that map is often more valuable than recovering the control logic, because a replacement board with the wrong acceptance filters is silent to the rest of the machine.
The data converter interface is the opposite case. On a motion controller it is configured and never used; on an audio-adjacent product it is the main data path. Whether its registers are touched is a fast way to tell which kind of product is on the bench.
The Physical Job
Eighty pins on a board with a power stage, two transceivers and a switching supply. In-circuit access is preferred where the programming header survives; where it does not, the device comes off and the pads near the corners dictate the risk.
Damage changes the plan but not the target. A part that lost bond wires can still yield its array if the silicon is intact, and the imaging route does not care whether the device was working when it arrived. Chip extraction analysis describes the assessment that precedes that work.
What To Deliver
The array with an explicit end address, the configuration block decoded, the device ID with revision, and the EEPROM separately. Plus two independent reads compared byte for byte, and a statement of which revision the source was — because that single fact decides what the customer can safely do with the image.
Reading firmware covers the capture side. Our services page lists the levels available, and contact us with the marking and a board photograph. The dsPIC30F6014 is the non-A part with the slower converter, and the dsPIC30F6013A is the 80-pin variant with twelve kilobytes less flash.