Secured MCU Breaker Experts!

A line on a purchase order reads “CF755”. That string is a top marking, not a catalogue number, and the distance between the two is where recovery jobs go wrong. Every read sequence — the voltage levels, the clock polarity, the entry command, the address map — is specific to a core and a mask set. Choose the sequence from the marking alone and you will either get nothing back or, worse, get something back and treat it as content.

The right order is identification first, extraction second. This note is about the first step, because on short-marked parts it is where most of the work is.

Three sources of identity, in order of reliability

The circuit context is the weakest source and the one people reach for first, because it requires no work. It is also where the expensive mistakes come from: a board that supplies three volts, has an eight-pin device and a single decoupling capacitor is consistent with several dozen microcontrollers from half a dozen vendors, and the recovery sequence for each of them is different.

Why a short marking cannot be trusted

Marking codes exist because packages are small. Manufacturers abbreviate the family, drop the temperature and package suffix, and encode the date and lot in a two- or three-character code. On a device that was second-sourced or re-marked — a practice that is common in consumer supply chains — the abbreviation on the package may belong to a different vendor entirely from the die inside.

Two practical consequences follow. A part whose marking resolves to one family but whose pin behaviour matches another should be treated as unknown until the die is seen. And a part presented as new stock with fresh silkscreen should be treated with suspicion if the rest of the board looks a decade old: the marking may be the most recently applied thing on it.

Four checks that narrow the field

None of these requires opening the package, and together they usually reduce the candidates to one or two.

Pin count and package. The pin count bounds the family. Device families are built around a package ladder — eight, fourteen, eighteen, twenty, twenty-eight, forty — and a part in a twenty-pin package cannot be a family member that only exists in eight and fourteen.

Supply and clock. Measure the rail, then measure the clock pin. A device with an on-chip oscillator and no crystal is a different candidate set from one driven by an external resonator, and the frequency tells you something about the intended application.

Behaviour at power-up. Sample every pin for the first few milliseconds. A part that drives a pin high immediately is executing code from an internal source. A part that leaves everything floating until an external signal arrives is waiting, which implies a different reset strategy.

Communication attempts. Only now, with a shortlist, try the programming entry sequences. A part that responds to one family’s entry command with a recognisable device identifier has been identified with near certainty, because the response contains a signature the vendor assigned.

The last step is the one that must be limited. Some entry sequences, applied with the wrong timing to a part expecting a different protocol, put the device into a test mode that is not always reversible. Probing blindly is a way to convert a recoverable part into an unrecoverable one.

What the die adds

Once the package is open, identification stops being inference. The top marking on the die carries the vendor’s mask code and often a revision letter; the layout shows the array structure, which distinguishes a flash array from an OTP array from a mask ROM at a glance; and the periphery shows whether there is an on-chip oscillator trim network, which narrows the family further.

On a job where the plan is decapsulation anyway, this is free information and it should be collected before the electrical read rather than after. Reading the die first occasionally reveals that the part is not the one on the paperwork, which is worth knowing before a report is written.

Why the dump is a separate problem from the read

“Dump” implies the whole array, including the parts that a normal programmer would skip. That means three things beyond the instruction stream: the configuration or option area, any factory-written identification or calibration region, and the address ranges that read as blank. A read that stops at the last non-blank word is not a dump; it is a program image with an assumed boundary.

On short-marked parts the boundary is exactly what you do not know, so a dump has to be taken over the full address space the identified family supports, with blank regions recorded rather than trimmed.

The assumption that costs the most

The recurring failure on jobs like this is choosing the read algorithm from the package. An eight-pin plastic part with five signal lines looks like a dozen devices, and a technician who has read a hundred of one family will apply that family’s sequence without checking. When it works, nothing is learned; when it does not, the device may be left in a state that requires decapsulation to recover, turning a routine read into a full job at the customer’s expense.

The discipline is cheap: two minutes of measurement and a documented shortlist before the first command is sent.

Where the part turns out to be a small OTP device in an eight-pin body, PIC12F508 code recovery covers the fixture constraints that follow. Where identification succeeds and the device is a two-array flash part, PIC16F685 flash deals with the protection bits. And where the device is confirmed as a PIC16F689 with a serial peripheral, PIC16F689 software continues with what the config word reveals about the board.

The short version

A marking is evidence, not an identity. Resolve it against package, supply, clock and power-up behaviour, confirm with a signature response only when the candidate list is short, and read the die marking before the electrical read if the package is coming off anyway. Then dump the full address space, blank regions included.

Reverse Engineering MCU ATMEGA48P Program from flash memory and copy heximal program to new microcontroller atmega48p secured chipset;

Not all 16-bit accesses uses the Temporary Register for the high byte. Reading the OCRnA/B/C 16-bit registers does not involve using the Temporary Register, To do a 16-bit write, the high byte must be written before the low byte. For a 16-bit read, the low byte must be read before the high byte.

The following code examples show how to access the 16-bit timer registers assuming that no interrupts updates the temporary register. The same principle can be used directly for accessing the OCRnA/B/C and ICRn Registers. Note that when using “C”, the compiler handles the 16-bit access.

unlock encrypted atmega48pv microcontroller protective system and dump embedded heximal file from flash memory

The assembly code example returns the TCNTn value in the r17:r16 register pair. It is important to notice that accessing 16-bit registers are atomic operations when breaking microcontroller atmega48p atmel avr chip fuse bit. If an interrupt occurs between the two instructions accessing the 16-bit register, and the interrupt code updates the temporary register by accessing the same or any other of the 16-bit Timer Registers, then the result of the access outside the interrupt will be corrupted.

crack secured mcu atmega48v fuse bit and extract embedded heximal file from flash memory

Therefore, when both the main code and the interrupt code update the temporary register, the main code must disable the interrupts during the 16-bit access after readout microcontroller atmega48pa binary file and heximal from eeprom and flash memory. The following code examples show how to do an atomic read of the TCNTn Register contents. Reading any of the OCRnA/B/C or ICRn Registers can be done by using the same principle.

If writing to more than one 16-bit register where the high byte is the same for all registers written, then the high byte only needs to be written once. However, note that the same rule of atomic operation described previously also applies in this case.

There is a command that resolves almost every ambiguity on arrival. Locked or damaged? Blank or unreadable? Interface working but the array throwing errors? One erase answers all of it, in about a second, and there is no undo.

That asymmetry — instant information, permanent loss — makes the erase the single decision in this work that most needs to be made by the person who owns the device rather than by the person holding the programmer.

What an erase actually does

The command is a chip erase, and its scope is wider than most people assume the first time.

Three consequences follow. The program is gone. The production data is probably gone, and on a device that has been in service that data is often irreplaceable. And the part becomes programmable, which is the only useful part of the outcome.

The fuses surviving is worth noting because it produces a device that erases cleanly, programs cleanly, and then does not start — because the clock source is still set to a crystal that the test rig does not have.

The diagnostic use, stated honestly

Erase does distinguish the three states that arrive labelled “dead”.

• A part that erases and then reads as blank was locked or had content. Either way, the interface works and the silicon is functional.
• A part that refuses to erase has an interface problem, a power problem, or a genuinely damaged die.
• A part that erases and then reads back with errors has a failing array.

That is real diagnostic value, and there is a way to get most of it without destroying anything. Read the signature, read the fuses, read the lock bits, attempt a read of the array, and observe which of those four steps fails and how. In the majority of cases that is enough to classify the device. Erase is the tool for the residual cases, not the first instrument to reach for.

When erase is legitimate

Three situations justify it, and all three have the same shape: the thing being destroyed has no value.

The image is already captured and verified. The arrays have been read twice, the two reads agree, the customer has the file. Erasing now is housekeeping, and it is the correct way to hand back a part whose protection state should match what the customer expects.

The device is a write-off. A part recovered from a failed board, a sample with a known-bad array, a unit whose purpose is to be sacrificed to answer a question.

The customer asked for it. Not “the customer wants the file”, but an explicit instruction to erase, with the consequences stated. That request belongs in writing, because the person who approved it may not be the person who discovers the consequence.

In every other case the answer is to read first, and to attempt the non-destructive routes — including the physical ones — before considering destruction.

The myth that erase unlocks

A persistent belief holds that erasing clears the protection and then the firmware can be read. This confuses two different states.

Erasing clears the lock bits, and it also clears the program. What remains is a blank array. The protection is gone because the protected content is gone, which is not a recovery, it is a deletion that happens to leave the part usable.

The same misunderstanding appears in the other direction when someone erases a device to “reset” it after a failed update. That works, in the sense that the part returns to a programmable state, and it destroys whatever partial image was there — including the portion that would have made a repair possible.

The procedure that removes the temptation

The discipline is procedural rather than technical:

1. Read fuses, lock bits, signature, calibration row. Record.
2. Read flash. Read again. Compare.
3. Read EEPROM. Read again. Compare.
4. Confirm both images are on storage that is not the laptop you are about to close.
5. Only now, if there is a reason, erase.

Step four is where projects fail. An image held in a session buffer is not a delivered image, and closing the wrong window at the wrong moment has destroyed more data than any erase command.

What to write down afterwards

If an erase happens, the delivery should say so: that the part was erased, what was lost with it, and what state it is in now. That sentence is unpleasant to write and it is the difference between a professional handover and an argument three weeks later when someone tries to read the device again and finds it blank.

Related reading

• ATmega1280A and reading on a live board — the non-destructive route in practice.
• ATmega1284V and restoring the fuses — what survives an erase and what does not.
• ATmega1284PV and the identity in EEPROM — the data an erase is most likely to destroy.

FAQ

Does the save-on-erase fuse protect the EEPROM from all erases? It protects it from a chip erase. A deliberate EEPROM erase command still clears it.

Can an erased part be identified afterwards? The signature and the fuse settings remain, so the part can be identified and configured. The content cannot.

Is a page erase safer than a chip erase? It is narrower, which is not the same as safe. On most parts the page erase is still a destructive operation on that page.

What if the lock bits are set and the read returns zeros? That is the expected behaviour. It confirms locking, not damage. Erase would confirm the interface works, at the cost of the content.

Conclusion

The erase answers every question and destroys the evidence. Do the four reads first, keep the files somewhere durable, get the destruction agreed in writing if it is going to happen — and remember that clearing the lock bits is not the same thing as recovering what they protected.

The datasheet describes a device with a programming interface, a defined clock range, and a documented way to enter programming mode. The board it is soldered to describes something else: pins shared with a display bus, a reset line held by a supervisor, a ground plane connected through a hundred vias, and a power rail that is switched by the product’s own firmware.

The gap between the two descriptions is where most of the time goes on a part this size. None of it is a silicon problem, and all of it decides whether the job takes an afternoon or a week.

The pins that are not available

On a hundred-pin package the programming interface uses a handful of pins, and on a dense board those pins are frequently doing something else. Two situations recur.

Shared with the external memory bus. This part can drive an external bus, and products that use it put the data and address lines on the same pins the programming interface needs. The firmware configures those pins as bus signals within microseconds of reset, which means the window in which the programmer can talk is the window between power-on and the first configuration write.

Shared with a display or a keypad. Slower, but the same problem: the application drives the pins as soon as it starts.

There are three ways to deal with it, in increasing order of intrusiveness. Hold the part in reset and release it only when the programmer is already driving the clock. Slow the entry down by choosing the lowest possible programming clock, which extends the window. Or take the part off the board, which removes the problem and introduces others.

The reset line is not yours

A supervisor IC, a host processor, or a push button circuit is usually attached to the reset pin. Any of them can pull it low during a session, and a single glitch in the middle of a page read produces a corrupted page rather than an error message.

The measurement comes before the fix: put a scope on the reset pin and watch it for thirty seconds with the product powered normally. If the line moves at all, it needs to be isolated during the read — a series resistor is not enough on most boards, and lifting the pin or cutting a trace is a decision to make with the owner’s consent, not unilaterally.

Power, ground, and the assumption that fails

The programming interface is a synchronous serial link, and its reliability depends on the return path. On a board with a solid ground plane this is a non-issue. On a board where the connector’s ground is a thin trace shared with a switching regulator, the read errors look like bad silicon.

Two habits prevent this. First, attach the programmer’s ground to the same physical area as the part’s ground pins, not to a distant connector. Second, power the board from its own supply when possible rather than from the programmer, because the programmer’s supply cannot deliver the current a hundred-pin part draws when its peripherals are active.

The rework decision

Removing a hundred-pin fine-pitch package is a routine operation for someone who does it daily and a source of lifted pads for someone who does not. If the part is to come off, three things should be true: the board is not the only one in existence, the customer has agreed, and the removal is done with a controlled profile rather than a hot air station at full power.

For leaded packages the risk is manageable. For packages with a thermal pad the risk is a warped board and a part that never sits flat again. In that case the in-circuit route is worth more effort than it first appears.

What the read gives you on this part

Once the interface is cooperating, the array is large but not complicated, and the extraction itself is uneventful. What matters afterwards is that this part usually comes with neighbours: an external memory device, a display controller, a radio. The firmware may hold a copy of a table that also exists in an external serial memory, or it may fetch assets from it.

If the product has external memory, the recovery is not finished when the internal array is read. Ask what else is on the bus, and read that too while the board is open and accessible. Reopening it later costs the same as opening it now, and the second visit is always more awkward.

Documentation that prevents a repeat

Every in-circuit job produces a small amount of knowledge that is expensive to rediscover: which pins had to be isolated, what clock rate the link tolerated, where the ground was taken, whether the part had to be held in reset. That belongs in the delivery as a short procedure, because the same customer will have a second unit.

A one-page note is enough. The value is not in the elegance of the document; it is in not paying for the same discovery twice.

Related reading

• ATmega1280PV and the three-byte program counter — what changes in the code once the array is out.
• ATmega1280PA and the erase you should not run casually — the destructive option, and when it is legitimate.
• ATmega640 and when part of the program is off-chip — the same package family, the same neighbours.

FAQ

Can the part be read while the application is running? Not reliably. The programming interface needs the part in its own mode, which the running application will not stay in.

Does holding reset damage anything? No, provided the programmer supplies the clock. It is the standard way to get a quiet window on a busy board.

What if the reset pin is fused as a general-purpose input? Then the only entry is through the programming interface without the reset function, which limits the options considerably and may force part removal.

Is removal always riskier than in-circuit? For a fine-pitch package on a thin board, usually yes. For a socketed or leaded part, no. The decision is per board, not per rule.

Conclusion

On a part this size the silicon is rarely the obstacle. Isolate the reset, take the ground seriously, decide about rework with the owner, and record what worked — because the second unit of the same product will arrive eventually.

Short reads hide problems. A two-kilobyte dump completes before anything has time to change, so the supply is the supply, the part is cold, and the contact resistance is whatever it was at the start.

A large array changes that. The read takes minutes, and over minutes three variables move: temperature, supply, and mechanical contact. Each of them shifts the margin, and the effect is a file that begins correct and ends wrong.

What drifts and how much

The first row is the one that is usually ignored. A part that has been powered for a while is warmer than one that has just been inserted, and the internal oscillator’s frequency moves with temperature. Because the serial interface is synchronous against the target’s clock, a shift in frequency shifts the sampling point.

Why the failure is silent

The interface does not report a marginal sample. It reports success and returns a byte. The byte is whatever the sense amplifier resolved, which on a marginal access may be wrong.

So the failure appears as content, not as an error. On a large array, that content is far from where the analyst is looking: the first pages are read carefully, the middle is skimmed, and the error sits somewhere in the eighth kilobyte.

Three checks that cover the session

Per-page double read. Compare each page against itself immediately. This catches instability at the moment it happens, rather than later when the cause is gone.

End-point re-read. Read the first page again at the end and compare with the first pass. If it still matches, the setup was stable across the whole session. If it does not, the entire file is suspect, including the parts that looked fine.

Page map. Record the number of non-erased words per page. A page that suddenly reads as all FF in the middle of populated code is either erased or misread, and the map makes it visible.

The second check is the cheapest and the most informative, because it converts an unbounded worry into a binary answer.

The picoPower and low-voltage combination

PV combines two things that both narrow margin: the picoPower die with its revised oscillator, and the extended low-voltage range.

At the design rail neither is a problem. At the bottom of the range, the oscillator is less accurate and the sense amplifiers have less to work with, and a long read gives both more time to drift out of specification.

The practical conclusion is unglamorous: power these parts at their design rail, not at the bottom of their range, and accept the seconds of extra settling that a stable supply requires.

Reading procedure

1. Supply at the design rail, measured at the socket, with local decoupling.
2. Signature, fuses, lock byte.
3. One page read twice; require equality before proceeding.
4. Full read in passes with per-page verification and a page map.
5. First page re-read at the end.

Steps 3 and 5 bracket the session. Between them, step 4’s page map is the record of what happened, and it is the artefact worth keeping alongside the image.

Related notes

• ATmega128V and the boundary register — where the image’s data actually lives.
• ATmega128P and binary layout — the file format that hides a truncation.
• ATmega324PA and marginal reads — the same physics on a smaller array.

FAQ

Does temperature really matter for a flash read? It shifts the oscillator and the sense amplifier behaviour, which is enough to change a marginal sample.

How long is a 128 KB read? Minutes at a conservative clock, which is exactly why drift becomes relevant.

Can a bad file be detected after the fact? Only by the checksums and page maps recorded during the read. Without them, a plausible file cannot be distinguished from a correct one.

Is a faster read worth the risk? Only if the page-level verification is kept. Speed without verification is how partial images get delivered.

Conclusion

Long reads fail differently from short ones: not by erroring, but by drifting. Bracketing the session with a repeated first page, verifying each page as it arrives, and keeping a page map converts an invisible risk into a recorded measurement — which on a large array is the only evidence that the file is what it claims to be.

Everything about this device is different from a microcontroller, and the habits carried over from firmware work are actively unhelpful. There is no instruction set, no program counter, no stack. There is an array of connections between sixteen input signals and eight output macrocells, and what it implements is whatever those connections happen to compute.

The good news is that the output is more useful than a firmware dump. Equations can be read, checked against a truth table, and re-implemented anywhere. The bad news is that the recovery question is not “can I read it” but “is the array still readable”, and that depends on one bit.

The architecture in one paragraph

Twenty pins: sixteen inputs, eight outputs, power and ground. Each output pin drives a macrocell, and each macrocell contains a flip-flop, a set of multiplexers, and an output enable. The AND array has sixty-four product terms of thirty-two literals each — two literals per input signal, true and complement — and the macrocells combine those terms into sum-of-products logic, either combinationally or registered.

That is the whole device. Two thousand and forty-eight array bits plus a small number of architecture bits, and the architecture bits decide what the array means.

The bit that decides whether there is a job

The security cell is a single bit whose only purpose is to stop a programmer from reading the array. When it is set, a read returns a legal-looking file whose array section is all zeros or all ones, and a JEDEC reader will happily parse it and produce nonsense.

Recognising that pattern is the first skill. A real array is never uniform; a secured one is. If every product term decodes to either “always true” or “always false” — that is, every row is either all fuses intact or all fuses blown — stop, because you are looking at the security state, not at the logic.

Whether the cell can be cleared depends on the manufacturer and the date code. Some parts allow a bulk erase that clears both the array and the security bit, which reopens the device for reading only because the logic is gone with it. Others treat the cell as one-time. Establishing this from the specific part marking, before spending a day on a plan, is the sensible order of events.

Decoding the array

For each of the sixty-four rows, the thirty-two array bits say which literals participate in that product term. Under the standard convention an intact link contributes its literal and a blown link does not, and a row with every link blown is a term that evaluates to true unconditionally.

Read the rows in order, and the structure of the design becomes visible, because designers and compilers both write in patterns:

• Consecutive rows feeding the same macrocell are usually the terms of one output.
• A row containing a single literal is usually an enable condition or a clock qualifier.
• Blocks of rows that reference the same few inputs are usually a decoder — an address comparison, a state decode, a chip select.
• Rows that reference an output’s own feedback are usually latches or state machines, and they are the ones that need care.

The macrocell mode is half the meaning

The same array bits mean different things depending on how the macrocell is configured. In combinational mode the sum of products drives the pin directly. In registered mode the sum feeds a flip-flop clocked from a dedicated pin, with the output enable on another pin. In the third mode the output is a dedicated input and the term structure changes again.

Getting the mode wrong produces equations that look plausible and behave nothing like the original, which is a failure that only shows up when somebody builds a replacement and it does not work. The mode is set by architecture bits in the file and, on many parts, is also inferable from the pin usage on the board: a clock on pin one and an enable on pin eleven means the registered configuration is in play.

From equations to something that runs

The output of the decode is a set of Boolean equations, one per output, in sum-of-products form. Three things follow from that, and all three are worth doing before touching a soldering iron.

Minimise and sanity-check. Feed the equations through a logic minimiser and compare against the original term count. A design that shrinks from twenty terms to four was probably mis-decoded.

Verify by exhaustive simulation. Sixteen inputs is sixty-five thousand combinations. A simulator covers all of them in well under a second, and comparing the re-derived equations against the decoded array row by row eliminates the entire class of transcription error that this work is prone to.

Choose a target. A modern CPLD accepts the equations directly. A small microcontroller can implement them in software if the timing allows, which is usually the case for a slow glue-logic design and never the case for a fast one. Knowing which kind of design this is determines the answer.

Why this matters for legacy products

These parts sit in equipment that was designed in the late eighties and nineties and is still in service: industrial timers, machine tool interlocks, instrumentation front panels, bus arbiters. The logic is trivial by modern standards and completely undocumented, and the original designer is retired.

A recovered equation set is a complete specification. It is more portable than a firmware image, more readable than a schematic someone reverse-drew from a photograph, and it can be re-implemented on a part that is still manufactured. That is the whole value proposition, and it is why the effort of learning the fusemap format pays off on the first job.

Related reading

• ATmega1284 and what an image does not contain — the equivalent problem for a device that does contain a program.
• ATmega1284V and how initialised data sits in the image — tables versus code, in a different architecture.
• ATmega128PA and a fuse that changes the machine — another case where one bit redefines everything.

FAQ

Can a secured GAL16V8 be read at all? Not through the programming interface. The array is inaccessible while the security cell is set, and whether that cell can be cleared varies by manufacturer and process.

How long does a decode take? The mechanical part is quick. The interpretation — deciding what each term is for — is the work, and it typically runs to a few hours for a design of this size.

Is the electronic signature useful? Often. It frequently holds a part number, a date code, or a pattern the designer chose, and it survives independently of the array.

Can the equations be rebuilt from a working board by probing? For slow designs, sometimes, by driving inputs and observing outputs. That produces a truth table, not equations, and it misses any state the device holds internally.

Conclusion

A logic device is a table of connections, and the job is to turn the table back into equations that a person can read and a modern part can implement. The only real obstacle is one bit, and everything after it is methodical.

An 8-bit microcontroller with 128 KB of flash has a problem: 128 KB is 65,536 words, and a 16-bit program counter can address exactly 65,536 words. There is no room left for the next instruction.

The solution is a third byte on the program counter. It works, it is invisible to most code, and it leaves fingerprints all over a disassembly that are routinely mistaken for corruption.

What changes at the boundary

Three things, and each one shows up in an image.

The return address on the stack becomes three bytes. A call pushes three bytes instead of two. Code that manipulates the stack directly — a context switch, a hand-written interrupt prologue, a bootloader that relocates itself — has to know this. An image disassembled assuming two-byte returns will show a stack that appears to be drifting.

Long jumps need a register that holds the high byte. On smaller members the jump target fits in the instruction. Here the target’s upper bits come from a register written before the jump. A JMP therefore has a visible predecessor instruction, and the pair must be read together.

Constant data in flash needs a pointer with a high byte. Tables addressed through a 16-bit pointer cannot reach the top half of the array. The compiler inserts a load of the high byte before the table access, which in a disassembly appears as an otherwise unmotivated write.

Why the vector table looks strange

Interrupt vectors are jump instructions, and on this part the unconditional jump is a two-word instruction whose target is split: low bits in the instruction, high bits from the register.

That means a vector table where every entry is two words plus a preceding register load. In a naive disassembly the table looks padded, or looks like it contains data rather than code, because the register load before each jump reads as an unrelated instruction.

Recognising the pattern is the whole trick. Once the shape is known — load high byte, jump — the table becomes readable and the section boundaries become obvious.

The V suffix and the P suffix together

PV combines two independent things: the low-voltage grade and the picoPower die. Neither changes the program counter, the address space, or the file format.

What they change is the electrical envelope during a read. A 128 KB array read at a marginal supply or at an excessive clock rate produces pages that fail intermittently, and on a part this large the read takes long enough that a supply sag can occur midway. The symptom is a file that is correct at the start and wrong at the end.

The defence is structural: read in passes, verify each page twice, and re-read the first page at the end. If the first page still matches, the supply held; if it does not, the whole file is suspect regardless of how plausible it looks.

Interpreting a large image

With 128 KB there is enough space for structure that a small part cannot hold: multiple tables, a bootloader, a string section, sometimes an unused region between the application and the boot section.

The gap is informative. A gap that is exactly the boundary between the application region and the boot region confirms the boot size fuse. A gap that is somewhere else suggests the application does not fill its space, which means the build was for a larger part than the one in hand — a common situation with a family that shares a die.

What a recovered image cannot tell you

The image says nothing about the fuses. On a part where the boot reset fuse redirects the reset vector, the image alone gives a misleading picture: the code at address zero may be perfectly good and still never execute.

It also says nothing about the external memory interface. If the bus is enabled and code lives in an external device, the internal image is a fragment — and on this family the bus is present, so that possibility is real rather than theoretical.

Both are answered by reading the fuse byte, which is one command and takes a second. Doing it first is not caution, it is the difference between interpreting an image and guessing at one.

Related notes

• ATmega1280P and the EEPROM array — the separate memory this part also carries.
• ATmega1281PV and reconstruction — the sibling without an external bus.
• ATmega640 and external code — why an image can be a fragment.

FAQ

Does code compiled for a 64 KB part run on this one? Usually yes. The wider program counter is transparent to code that does not depend on address size.

Why do returns look wrong in my disassembly? Because they push three bytes. A two-byte assumption shifts every subsequent stack reference.

Can the whole 128 KB be executed? Yes. The address space is fully populated on this member, unlike a smaller part in the same family occupying a subset.

Does the V grade limit clock speed? At the low end of the supply range, yes. That interaction is what makes long reads riskier on this part.

Conclusion

The third program counter byte is the single fact that changes how a large AVR image must be read. It shows up in return addresses, in jump instruction pairs, and in table accesses, and each of those looks like an error if the assumption is wrong. Knowing the shape turns the vector table from noise into the most structured region of the file.

When a part has 128 KB of program memory, the EEPROM beside it looks like an afterthought — a few kilobytes at most. In practice it is the part of the device that carries the identity: serial numbers, calibration constants, usage counters, per-unit keys. The flash is the same in every unit; the EEPROM is what makes each unit distinct.

It is also the array with the most unusual rules, because it is addressed separately, written slowly, and its survival through an erase depends on a single fuse.

A different address space

EEPROM is not mapped into the program address space. It has its own instructions, its own control register, and its own read and write paths:

The write-time row is the one that catches people out. Writing a byte takes roughly the same time as writing a whole flash page, which means a firmware that logs to EEPROM frequently is spending most of its time waiting. It also means a device that loses power mid-write can leave a byte in an indeterminate state — a real phenomenon, visible in dumps as isolated anomalies in an otherwise orderly table.

What a reading of the EEPROM tells you

Three categories of content appear again and again:

Identity. A serial number, a build date, a hardware revision code. Short, structured, and immediately useful because it dates the device and often reveals which firmware build it shipped with.

Calibration. Offsets and gains measured per unit at the factory. This is the most valuable category for anyone trying to reproduce behaviour, because these values are not in the firmware and cannot be derived from it.

State. Counters, flags, a last-known-good record. Useful for understanding what the device has been through, and occasionally for understanding why it failed.

A blank EEPROM in a device that should have one of these is a strong signal: the part was erased, or the fuse allowed the erase to take it, or the device was never production-calibrated in the first place.

The fuse that decides survival

Chip erase clears the flash and the lock bits together. Whether it also clears the EEPROM is decided by one fuse, active-low like the rest: programmed means the EEPROM is preserved.

This is set for operational reasons, not defensive ones. Products that update firmware in the field want calibration to survive the update. That decision, made for convenience, is what makes the EEPROM recoverable from a locked device: erase to clear the locks, and the EEPROM is still there.

When the fuse is not set, the erase produces a clean blank part and nothing else. Knowing that early is worth a great deal, because it converts an open-ended investigation into a closed one.

Reading it correctly

Two practical notes.

The read is byte-addressed and does not need page alignment, so a straightforward sequential read works. But the array is small and the interface overhead dominates, which means a read that seems slow is normal rather than faulty.

The read is gated by the lock bits exactly as the flash is. In mode 2 or 3 the EEPROM read command is refused along with the flash read command. So the sequence on a locked part is erase first, read second — and the only reason that sequence yields anything is the fuse above.

Why it matters more than the code, sometimes

Consider a product built around this part that measures something: a sensor interface, a power meter, an instrument. The firmware implements the algorithm. The EEPROM holds the constants that make the algorithm correct for that specific unit — the offset of this sensor, the gain of this amplifier, the scale factor of this shunt.

Reproducing such a product from a flash image alone produces a device that measures consistently wrong. Adding the EEPROM constants makes it measure correctly. The flash is the logic; the EEPROM is the truth about the physical unit.

That is why a recovery that returns only the program is often described as incomplete, and it is why the fuse read belongs at the very start of the process rather than at the end.

Related notes

• ATmega1280PV and the three-byte counter — the address-space question on the same family.
• ATmega2561V and EESAVE — the same fuse on the largest member.
• ATmega32PA and the EEPROM that outlives the flash — the mechanism explained from first principles.

FAQ

How large is the EEPROM on this part? It is a few kilobytes, small relative to the flash and large relative to a serial number and a calibration table.

Can the EEPROM be read without erasing? Only if the lock bits permit verification. In mode 2 or 3 the read is refused, and the erase that opens the door destroys the flash.

Does writing EEPROM wear out the flash? No, they are separate arrays with separate endurance figures. EEPROM is rated for far more cycles than flash.

Can EEPROM contents be transplanted to another part? Yes, mechanically. Whether it works depends on whether the values are per-unit, which they usually are.

Conclusion

On a large-flash part the EEPROM is small, separate, and disproportionately informative. Its addressing, its endurance, and its write timing are all different from flash, and its survival through an erase depends on one fuse that was set for operational convenience. Reading that fuse first is what makes the rest of the plan either short or impossible.

Every other operation on this part reads. Chip erase writes — it drives charge into the array to move cells back to their erased state — and it is the only operation that draws a burst of current large enough to move the supply rail.

On a full rail that burst is absorbed by decoupling. At the bottom of the specified range, with a long lead and a small capacitor, the rail dips during the burst. The erase then either completes with some pages only partially cleared, or aborts partway with no indication in the command response.

Why nothing reports it

The erase command returns when the operation’s internal timer expires. It does not verify what it did. Verification is a separate step that has to be requested, and the way to request it is to read the array back and look.

That design is reasonable — verifying inside the command would double the erase time — but it means the failure is silent by construction. A partially erased part behaves like a part with odd data in it, and odd data is exactly what a protected device is supposed to have.

The three visible consequences

The third row is the one that wastes the most time, because a page that is unchanged looks like a page that was never targeted. If the tool erased a range and the range came back unchanged, the natural conclusion is a wrong address — and the actual cause may be that the operation stopped.

Decoupling is the fix, and it is physical

Three details decide whether the burst is absorbed:

• Capacitance at the socket. Not at the supply, at the socket. The distance is what converts a capacitor into an inductor.
• Ground return. A shared ground with other equipment injects noise into the reference the pump uses.
• Lead length. Short and thick beats long and thin, every time.

None of this appears in a datasheet as a requirement, because the datasheet assumes a properly decoupled supply. On a bench with clip leads and a breadboard, the assumption is not met.

The picoPower wrinkle

The PA suffix marks a picoPower die. Lower sleep current, revised oscillator, more brown-out levels. None of that reduces the charge pump’s appetite during an erase — the array is the same physics.

What it does change is the brown-out detector’s behaviour. If the detector is enabled at a low threshold, a supply dip during the erase may trip it, and the part resets mid-operation instead of completing. The result is a partially erased part and a programmer that reports a communication error rather than an erase failure.

Disabling the detector is not the answer; providing enough capacitance is. But knowing that the detector can be the thing that interrupts an erase explains a class of failures that otherwise look random.

Ordering the operations

The sequence that makes erase failures visible rather than mysterious:

1. Power at the design rail and measure at the socket, under load if possible.
2. Read signature, fuses, lock byte. Record all three.
3. Erase.
4. Read the entire array back and confirm uniform FF.
5. Only then write.

Step 4 is the one that converts a silent failure into a visible one. It costs one full read of a blank part, which is fast because there is nothing to interpret.

Doing step 4 also validates the whole chain — supply, socket, adapter, clock, address mapping — before anything is written. If the array is uniformly FF after an erase, every part of the setup that matters has just been proven.

What to do with a part that will not erase cleanly

If repeated erases at the design rail with proper decoupling still leave non-FF bytes, three explanations remain, in order of likelihood: the socket contact is marginal on one pin, the die has a damaged page, or the part is not what it claims to be.

The first is fixable and cheap. The second means the array has a physical defect and no amount of retrying will help. The third is worth checking against the signature and the package markings, because a remarked part is a real phenomenon in this market.

Distinguishing them requires one more erase at a freshly seated part, which is a two-minute test and should always precede the more expensive conclusions.

Related notes

• ATmega640P and the three interfaces — which entry path the fuses left open.
• ATmega640PV and binary dumps — how an erase failure becomes an unreadable file.
• ATmega324PA and brown-out — the detector’s role in a marginal setup.

FAQ

Does chip erase verify itself? No. It completes on a timer. Verification is a separate read-back, and skipping it is how partial erases go unnoticed.

Can a partially erased part still run? No. The erase destroys the program. What remains is a mixture of FF and residue, which is not executable.

Is a supply dip visible on a meter? Rarely. The burst is short; a multimeter averages it away. An oscilloscope at the socket shows it in seconds.

Does the erase also clear the lock bits? Yes, and that is the only operation that does. It is why the erase is both the way past protection and the thing that destroys the contents.

Conclusion

Erase is the one operation on this part that loads the supply, and the one whose failure is invisible. Confirming a uniform FF after every erase is the cheapest possible test of the whole electrical chain, and on a picoPower part at the low end of its range it is not optional. What the command does not report, the read-back reveals.

Documentation lags silicon. A revision that left the fab last quarter may have no errata sheet worth reading, no change list, and a device signature byte that no tool recognises. The temptation is to treat such a part as “the same chip as last time” and proceed — and most of the time that works, which is exactly why the exceptions are expensive.

The alternative is to build a description of the part from measurements. Three of them are enough to catch the differences that matter.

Measurement one: the signature

Three bytes, read before anything else. Vendor and family are stable; the third byte is the model. When a revision changes nothing observable, the third byte is unchanged and the toolchain proceeds without complaint.

When it does change, the read still succeeds — the tool is what fails. Recording the three bytes is worth doing even when the part is recognised, because it is the one piece of evidence that identifies the die later in the process, and it takes a second.

Measurement two: the fuse and lock readback

The fuse map is stable across revisions, which makes it a calibration reference. Read it, record it, and compare it with what the image says should be there.

A discrepancy between the fuse byte you read and the assumptions in the firmware is informative. It can mean the device was reprogrammed in the field with different settings, that the part came from a different production run, or that the fuse byte is being read through a marginal interface. All three are worth knowing before an image is interpreted.

The lock byte readback is the same kind of evidence: it states the protection mode as the hardware sees it, which is the only authority on the question of whether a read is permitted.

Measurement three: erase behaviour

Erase the part and read it back. On a healthy part the array is uniformly FF and the lock bits are clear. Deviations from that, in order of frequency:

That table is the most useful diagnostic in the whole sequence, because it separates three things that otherwise look identical: a working part, a marginal setup, and a damaged die.

It also has a cost that must be stated plainly — the erase removes whatever was there. It belongs after the read has been attempted and after the decision that the contents are not recoverable by other means.

What the image says about the revision

Firmware written for a specific silicon revision often contains a workaround. Workarounds are recognisable: a redundant register write, a delay loop before a peripheral is enabled, a check of a status bit that the datasheet says is fixed.

Finding one in a recovered image is evidence about the die. A delay inserted before enabling a specific peripheral implies the revision needed it. That kind of code-level fingerprint is sometimes the only documentation a revision has.

It also matters for reproduction. An image restored onto a newer part carries workarounds that are unnecessary; an image restored onto an older part may be missing one that is essential. Neither failure mode is visible without knowing which revision the image was written for.

The practical stance

Treat an unidentified revision as a part whose electrical envelope is unknown rather than as a part identical to its predecessor. Concretely:

• Read at the design rail, never at the bottom of the range.
• Verify every page twice.
• Record signature, fuses, and lock byte with the image, not separately.
• Note the date code from the package, which is often the only revision evidence available.

The date code is underrated. It is printed on the part, it survives every toolchain’s indifference, and it distinguishes two otherwise identical units.

Related notes

• ATmega640 and the external bus — the shape question that precedes any revision question.
• ATmega640P and the three interfaces — which door the fuses left open.
• ATmega644A and revision footprints — the same problem on a smaller die.

FAQ

Does an unknown signature mean the part is counterfeit? No. It means the die is not in the tool’s table. Counterfeits usually reproduce a known signature rather than an unknown one.

Can I read a revision-specific fuse field safely? Reading is safe. Writing a fuse field whose meaning you are unsure of is not, because some settings remove the interface you would need to undo them.

Is the date code a reliable revision indicator? It is a production indicator. Two units with different date codes may still be the same revision, but two different revisions cannot share a date code.

Should workarounds be removed from a recovered image? Only with an understanding of what they compensate for. Removing one that was still necessary produces an intermittent fault that is hard to trace.

Conclusion

An undocumented revision is not a mystery, it is an unmeasured part. Signature, fuse readback, and erase behaviour describe it well enough to work with, and the workarounds inside its firmware often document it better than any published note. The mistake to avoid is assuming continuity — that is the assumption whose failures cost the most.