Secured MCU Breaker Experts!

Posts Tagged ‘decap microcontroller program’

There is a stage in every recovery between “the array answered” and “the customer can use it” that nobody photographs: turning a sequence of twelve-bit words into a file. It looks like a formality and it is the stage where most disputes are born, because a hex file for this class of device is a container with its own arithmetic, and there is more than one legal way to fill it.

The PIC16C57 makes the problem concrete. Two thousand and forty-eight words of twelve bits is 24,576 bits, which is three thousand and seventy-two bytes exactly. There is no way to store one twelve-bit word in a whole number of bytes, so every convention that exists is a compromise, and the compromises do not agree with each other.

The arithmetic first

Two rows are the ones to hold on to. A 3072-byte image is not a truncated 4096-byte image; it is the same memory written in a denser notation. And because the part addresses 2048 words, the sixteen-bit address field of an Intel HEX record is more than sufficient, which means no extended-address records are needed at all on this device.

Two words in three bytes

The packed convention splits each pair of twelve-bit words into twenty-four bits and writes them as three bytes, most significant byte first. Decoding is a shift and a mask, and it is exact. The unpacked convention writes each word as two bytes, little-endian, with the top four bits of the second byte always zero, which wastes a quarter of the file and makes the mapping trivial to inspect with a hex viewer.

Both are correct. The failure mode is a customer who receives one and burns it with a programmer set to the other. The programmer does not complain, because the file is well-formed either way; it simply writes 3072 bytes into a 4096-byte space and leaves the upper thousand words blank. The device then fails at the first address above 3071 bytes, which on a paged part is somewhere in page two, and the symptom looks like a page-select bug rather than a file convention.

The fix is procedural and cheap: put the convention in the file name and in the first line of the delivery note. image_packed_3072.hex and image_word_4096.hex cost nothing and remove an entire class of support call.

Record framing, and the fields that matter

An Intel HEX file is a sequence of text records, each starting with a colon and containing a byte count, a sixteen-bit address, a record type, the data and a checksum. Three of those fields do real work in a recovery.

The byte count tells the reader how many data bytes follow. It is also the field that most often disagrees with reality when a tool that was written for eight-bit parts generates the file: a record that claims sixteen bytes but carries twelve produces a reader error, and a reader that ignores the count silently misaligns everything after it.

The address is a word address on a twelve-bit part, not a byte address, and this is the single most common source of an image that is exactly twice as long as it should be or exactly half as long. A tool that converts word addresses to byte addresses and then writes them back as word addresses produces a file whose records are spaced two apart, and a programmer that honours the addresses leaves every second word blank.

The record type field is where the end-of-file marker lives. A file without a terminator is accepted by some programmers and rejected by others, and a file with a terminator in the middle — which happens when two images are concatenated — truncates silently in the tools that honour it.

Checksums are not verification

Every record ends with a checksum, and it is easy to treat a file that loads without complaint as a file that is correct. It is not. The checksum proves that the text survived transport. It says nothing about whether the words are the words that were in the device.

Real verification against the device needs three separate comparisons: the number of words delivered against the number the device should contain, the first word against a decodable instruction, and a sample of addresses across each page against a second read. On a part this small the second read is cheap, and a mismatch between two reads is far more informative than any checksum.

Reading order that produces a usable file

The sequence that avoids almost all container problems is short.

Read the configuration word first, because it tells you whether the array will answer and what the protection state is. Read the array in ascending order and record the page state at every 512-word boundary, so the file can be annotated later. Compare the word count to 2048 before writing anything to disk. Then write two files, packed and unpacked, from the same buffer, so that the pair is provably the same memory in two notations rather than two independent reads.

The last step is the one that saves arguments. A customer who has both files can determine which one their programmer wants by inspection, and the two files can be diffed against each other to prove the conversion was lossless.

For what the array contains once the envelope is settled, PIC16C57C firmware covers the device side. For the protection model that decides whether the array answers at all, PIC16C56 code copying takes the fuse view. And for a part where the container problem is a one-byte-per-word question instead, PIC16F505 flash decryption shows the smaller case.

FAQ

Is a hex file the same as a binary file? No. Hex is a text container that carries addresses; binary is a flat image whose meaning depends on a convention agreed outside the file. For twelve-bit parts the convention is the whole argument.

Why is my image 3072 bytes when the datasheet says 2048 words? Because two words fit in three bytes. Both numbers describe the same array.

Does the file need address records above 2048 words? No. The part cannot address beyond 2047, and extended-address records in a file for this device are either leftovers from a conversion tool or a sign that the wrong device profile was selected.

The short version

The array is the easy half. The container has its own arithmetic, its own record framing and its own ways of being wrong while looking correct. State the packing convention in the file name, keep the word address as a word address, compare the length to the device before writing, and emit both notations from one buffer. That is a ten-minute discipline that removes most of the support load from a recovery programme.