Secured MCU Breaker Experts!

Posts Tagged ‘open ic software’

Some enquiries use the word open because the customer wants to see inside the chip, and some use it because that is the word in the trade. On the PIC16C52 they can point at very different work, because the windowed version of this part was built to be opened. A ceramic package with a quartz lid is not a barrier to be removed; it is a feature to be used.

What the window is for

Erasable parts were shipped in ceramic packages with a transparent lid so the array could be returned to all ones by exposing it to ultraviolet light. The lid is quartz because ordinary glass blocks the wavelength that matters. Once the charge is driven off the floating gates the part is blank, and the same socket that read it can program it again. That is why the order code carries a letter telling you the part is windowed, and why a stock of these parts can be reused indefinitely while the plastic version cannot.

Erase is a dose, not a duration

The data sheet specifies the erase as an integrated dose at a wavelength, and the practical instruction that follows is twenty minutes or so under a lamp of the stated intensity at a stated distance. Two failure modes account for most of the trouble. Under-erasing leaves cells that read as programmed on one pass and erased on the next, which produces a dump that changes between runs. Over-exposure is not usually harmful to the array but does cook the plastic of a socket, and repeated heating is what eventually kills the bond wires.

Why an erased windowed part is not a loss

For a customer whose goal is a working second unit rather than a copy of the original code, the window is the whole answer. Erase, reprogram with the image they already have, and the part is back in service. This is the cheapest outcome in the whole vocabulary of these jobs and it is routinely overlooked because the enquiry arrives as “the chip is protected, we need it opened”. The distinction between a part that is locked and a part that is merely full is the same one that PIC16LF54 protection turns on.

Where decapsulation is still required

The middle row is the one that destroys evidence: once the epoxy is gone the part cannot go back into the product, so the read has to be right the first time. The top row has no such risk, which is why the first question about any old PIC should be which package it is in.

What the window cannot tell you

Erasing a windowed part leaves no trace of what was in it, so the window is also a way to destroy the evidence while believing the part has been serviced. A part that arrives already erased, with a lid that has clearly been under a lamp, is a part whose contents are gone and whose history is now unknown. Recording the read, the checksum and the socket before the lamp goes on is the only way to answer the question later. It is dull bookkeeping and it is the difference between a documented device and an anecdote.

The sequence that pays

Read first, while the part still works, then erase, then reprogram from the image. Doing it in that order means a failed read costs nothing but the time, and the device is still returnable. Doing it the other way round, erase and hope, loses the original image permanently and turns a repair into a reverse engineering project. The order is worth writing into the work instruction, because under time pressure the temptation is always to reach for the lamp.

Limits worth stating up front

The window does nothing for a part whose protection is in a fuse that the erase cannot reach, and it does nothing for a die that has already lost charge to age. It also does nothing for the plastic part, which is the majority of what is found in the field. Where the part is plastic and the protection is set, the route is the one in decap of the 54A and decap of the 55, and the constraints of that work are described in breaking an IC. The 16C505 is in the same position, and its EEPROM question is a different one. Reading the array before the lamp is used is not caution for its own sake; it is the difference between a file and a memory of a file.