Secured MCU Breaker Experts!

Posts Tagged ‘ic breaking embedded memory’

A request arrives as one string of thirteen characters. It contains eight separate statements about the device, and the person who wrote it usually knows what two of them mean. That is not a criticism — the code is built for purchasing systems, not for engineers — but it does explain why the first reply to a recovery enquiry is so often a question.

For R7FA2L1AB3CFP the eight fields are all decodable, and once they are laid out it becomes clear that six of them are about commercial identity and two are about physical work.

The eight fields

The two rows that do work are the code-flash letter and the package suffix. Everything between them describes how the part was screened and what temperature it is guaranteed over, which matters enormously to a design and not at all to a read-out.

What the group field buys you

RA2L1 is a 32-bit Arm Cortex-M23 running to 48 MHz, with no floating-point unit and no cache. Inside the group the peripheral set is fixed: a capacitive touch sensing unit in its second generation, nineteen channels of twelve-bit successive-approximation conversion, a twelve-bit digital-to-analogue channel, CAN, several serial channels covering asynchronous, clocked and two-wire modes, a data transfer controller rather than a full DMA engine, AES with a true random number generator, and the low-voltage and watchdog blocks that every design ends up using.

Two numbers in that list are worth pausing on because they constrain what a recovered image can contain. The absence of a floating-point unit means any decimal arithmetic in the firmware is done by a software library, and that library has a recognisable shape. And the absence of a cache means the instruction stream executes from flash at a predictable rate, so timing loops in the image can be counted rather than measured.

The memory map is the other constant the group field fixes: 256 KB of code flash, 8 KB of data flash, 32 KB of static RAM. All three are separate address ranges, and that separation survives into the recovery report — the two flash arrays are read through different mechanisms and delivered as different files.

What the package field costs

Eighty-five general-purpose I/O pins on the hundred-pin body is a generous number, and it is the reason this particular suffix appears so often in industrial designs. But a recovery never uses eighty-five pins. It uses two, plus a mode pin, plus ground and whatever supply the adapter needs.

The consequence is that a hundred-pin part is easier to work on than a forty-eight-pin one for a reason that has nothing to do with pin count as a specification: the pins exist, they are brought out, and there is room to clip onto them. On smaller packages the same two signals are often shared with functions the board actually uses, and the header may not exist.

That is why the package suffix is one of the two fields that changes the work. Not because the silicon differs, but because access differs.

The image proves itself in its first eight bytes

Cortex-M images have a property that makes them unusually easy to authenticate: the vector table sits at address zero, its first word is the initial stack pointer and its second word is the reset handler address.

That gives three checks before any disassembly:

1. The first word should point at the top of a 32 KB SRAM region, which is a value in a narrow and recognisable band.
2. The second word should point inside the code flash range, and it should be odd — the low bit marks Thumb state, and a Cortex-M reset vector with a zero low bit is not a valid entry.
3. The number of vectors times four should not exceed the space before the first function.

A base address error, a byte-order error or a truncated read all break one of those three. A correct image passes all of them without any tooling.

The three doors, and which one a lock closes

Access to this family is through one of three routes, and they are independent enough that closing one leaves the others open in ways that surprise people:

• The debug port, two wires, gated by a set of identification words the tool must present.
• The boot firmware, entered by holding a mode pin at reset, which speaks a serial protocol and does not need the debug port at all.
• The silicon itself, which no configuration reaches.

The first two are configuration-gated and the third is not. A part that refuses the debugger may still accept the serial protocol, and a part that refuses both is not necessarily destroyed. Knowing which door a given refusal applies to is most of the diagnostic work, and it is the subject the rest of this series returns to.

What comes back

A software-level recovery on this part returns the code flash as a binary or Intel HEX image of the correct 256 KB length, the 8 KB data flash as a separate file because it is a separate address range, the configuration words found at their fixed addresses, the identification words as read, and a disassembly with the vector table resolved into named handlers.

The data flash deserves its own file for a reason that is easy to state and easy to get wrong: it is not an EEPROM. It is flash, at a different address, with flash erase granularity and flash endurance. Treating it as a small EEPROM in the report sets up every downstream decision incorrectly.

The identification words are the other item worth naming explicitly. Where they were set, the report should say so, because it changes which access route a future attempt should use.

The identification mechanism has its own page in this series — R7FA2L1AB2DFN locked program recovery — and the route that bypasses the debug port entirely is covered in R7FA2L1AB2DFM software recovery. A second, earlier page on a different member of the same group is at R7FA2L1A92DFL binary extraction.

FAQ

Is the 100-pin part different silicon from the 48-pin one? No. The die is the same within a flash and grade combination. What differs is the package, the number of bonded-out pins, and therefore the access.

Does the quality grade affect readability? Not the mechanism. It affects screening, documentation and the guaranteed temperature range.

What is the first thing to check on a returned image? The first two words: initial stack pointer and reset vector. They validate base address, byte order and completeness in one look.

Conclusion

Read the code from both ends. The group field tells you the architecture and therefore the whole toolchain. The flash letter and the package suffix tell you the image length and the access route, and those two decide the job. The four fields in the middle are about how the part was sold and how hot it may run, and they belong in the report rather than in the plan.

Engineers who ask about a heximal file are usually asking the right question in the wrong order. The file is the last decision in a recovery and the cheapest: once the bytes exist, converting between record formats is a script. What determines the cost, the schedule and the risk is the body the die is in, and that information is in the ordering code, three fields before the hash.

R5F562TAEDFM#V1 is one of the larger-memory order codes in the RX62T group. The package field is a single letter pair, and it resolves to a specific body in the ordering table — a lookup that takes a minute and changes everything that follows. The version suffix identifies a shipping configuration and no silicon property.

Four body categories, four routes

The fourth row is where a quotation can be wrong by an order of magnitude. A fully encapsulated leadless body offers no route from the top at all, and the work moves to the underside: thinning the package, reaching the die through the substrate, and probing from behind. The die survives; the package does not, and the process is slower at every step.

What leadless changes

Three things, and they are all practical rather than theoretical.

There is no opening over the die, so the usual chemical approach has nothing to remove. What has to be removed instead is the substrate under the die, and that is a different process with a different failure mode: uneven thinning produces a die that is intact but cracked, and a cracked die reads inconsistently rather than failing outright.

The bond pads, if they can be reached at all, are reached from the same side as the substrate, which means the probe has to be positioned with much less clearance. On a die of this size that constrains the probe card and it constrains how many signals can be brought out simultaneously.

And the thermal path is part of the package. A leadless body with an exposed pad uses the pad as a heat spreader, and the die attach under it is designed to conduct. Removing the substrate means removing the thermal interface, and the die’s behaviour under probe changes — a device that ran at one temperature now runs at another, which matters if the fault being investigated is thermal.

Planning from the ordering code

Three fields settle the plan before the unit is touched.

The group tells you the architecture, so the reading strategy and the verification checks are known.

The memory class tells you how many bytes to expect, which sets the size of the buffer and the duration of the probe session.

The package field tells you the route, the fixture and the risk. This is the field that should drive the quotation, and it is the field most often ignored because it is the least familiar.

A fourth field, the version suffix, tells you nothing about any of the above and should not be allowed to influence the plan.

What survives and what does not

The die survives, in every route, which is the point of the exercise. The bonding wires survive in most top-side openings and are lost in backside work. The lead frame survives in leaded bodies.

The package does not survive. This is worth stating to a customer in the first conversation rather than the last, because a meaningful fraction of enquiries are from people who hoped to have the unit returned working afterwards. On a leaded body that hope is occasionally realistic if the work is non-destructive; on a leadless body it is not.

The board survives if the part is removed cleanly, and on a leadless body removal is itself a thermal event that the surrounding components may not tolerate.

Why the file format is the easy part

Once the bytes exist, the container question is small: the RX architecture places vectors at the top of a four-gigabyte space, so the file needs thirty-two-bit address records, and S3 is the conventional choice. Length, checksum and the reset vector are the three checks.

None of that is difficult and none of it is where a project fails. A project fails when the package was misread at the quotation stage and the backside work was priced as a top-side opening.

For the container question itself, R5F562T7EDFF heximal covers records and address width. For the identification that comes before any of it, R5F562T7DDFF code deals with the ordering suffix. And for what the bonded pins say about the firmware inside, R5F562T7DDFK program takes the pin-count view.

FAQ

Can a leadless part be read without backside work? Only if the debug or programming interface is open, in which case no package work is needed at all. That is worth testing first on every unit.

Does the body affect the recovered content? Not the bytes. It affects the confidence, because a harder access route means more marginal reads and a greater need for a second pass.

Is a differently packaged device the same die? Usually within a group, which is why a recovery on a leaded part is a useful reference for a leadless one — and sometimes a cheaper source of the same firmware than opening the leadless unit.

The short version

Read the package field before quoting anything. Leaded bodies open from the top; fully encapsulated leadless bodies do not, and the difference is the largest single variable in the cost. Test the programming interface first, because if it is open the body never matters, and treat the record format as the five-minute decision it is.

Ordering codes for this family end with a hash and a short code: #V1, #V3, #11, #13, and in this case #V0. Engineers read those suffixes as if they were software version numbers, and the inference goes like this: V0 is the earliest, therefore this is early silicon, therefore it has errata, therefore the recovery will need special handling.

None of those four steps follows from the first. The suffix is a shipping and configuration identifier assigned to a purchasing variant of a device. It is not a maturity scale, and the numbering does not run in the order that intuition suggests.

The base code here is R5F562T7DDFF: RX62T group, thirty-two-bit core with a single-precision FPU, two twelve-bit converter units, the six-channel motor timer and the inverter protection logic.

What varies and what does not

Two rows deserve emphasis. The die does not change, which means a recovered image and a listing are the same work regardless of the suffix. And errata applicability follows the actual mask revision, which is a physical fact about the unit in hand and cannot be read from a purchase order.

Why #V0 is not evidence of a prototype

The suffix numbering is assigned per configuration, and configurations are created for commercial reasons: a different packing, a different quality documentation package, a customer-specific label. The first configuration created for a base code does not have to be the earliest silicon, and a base code introduced recently can start at any suffix the ordering table happens to use.

There is a second reason the inference fails. A suffix that appears to be a low number may simply be a different family of codes entirely — quality grades and version codes often use different formats, so #11 and #V1 are not adjacent points on one scale.

The consequence in practice: a customer who says “this is a V0 part, so it is an early sample, so the firmware must be a prototype” may be describing a device manufactured last year. The physical evidence contradicts the inference, and the physical evidence wins.

How to establish the actual revision

Three sources, in order of authority.

The marking on the package, which carries a date code and often a lot identifier. The date code is the only reliable statement about when the unit was made.

The order and delivery records, if the customer has them, which identify the configuration that was bought.

And the device signature, which confirms the model and nothing about the revision — a point worth stating because so many people expect the signature to answer this.

Where the three disagree, the date code is the arbiter for age and the records are the arbiter for configuration.

What it means at the bench

The practical effect of a suffix is small, and it is worth saying so plainly because it is often used to justify a price difference.

Reading, protection behaviour, the boot protocol and the ID-code mechanism are properties of the group. They do not vary by suffix.

What can vary, and this is the one case where the suffix matters for analysis, is the documentation revision that describes a peripheral. A design written against an earlier revision of the hardware manual may configure a peripheral with a sequence that the current manual no longer describes, and a reviewer working only from the current manual will call that sequence an error.

The remedy is not to guess from the suffix but to keep two revisions of the manual available and check a suspicious sequence against both.

What this means for a quotation

A suffix that has been read as “early silicon” attracts a surcharge that is not justified by any technical difference. A suffix that has been read as “current” invites an over-confident schedule.

The defensible position is that the suffix affects paperwork and packing, that the work is priced from the group, the protection state and the package, and that any genuine errata question will be settled from the date code and the observed behaviour rather than from the order code.

For the package field that actually does change the work, R5F562TAEDFM heximal covers access by body type. For the ordering code read field by field, R5F562T6ADFK software is the decoder. And for a version identifier that genuinely does change from unit to unit, R5F562T7ADFF binary covers the firmware revision string.

FAQ

Are #V1 and #V3 different devices? No. They are two purchasing configurations of the same silicon, and the recovery work is identical.

Does the suffix affect the flash programming protocol? Not on this group. The protocol follows the family, not the configuration code.

Can errata be identified from the order code? Only indirectly. Errata follow the mask revision, which is inferred from the date code and confirmed by observing the behaviour.

The short version

The suffix is paperwork. The die is named by the group and the memory class, the body by the package field, and the work is priced from those plus the protection state. When a sequence in the code disagrees with the manual, check an older manual revision rather than blaming the order code.