STM32H747: The Display Configuration Is the Most Readable Part of the Image
June 5th, 2015 | 
Author: Most of a firmware image resists reading. Compiler optimisation dissolves the source structure, inlining removes the call graph, and what remains is arithmetic that has to be reasoned about instruction by instruction. A display pipeline is the exception. It is configured by writing numbers into registers, the numbers are properties of a physical panel, and a panel has a datasheet. This is why, on a part with a display controller and a MIPI interface, the graphics initialisation is usually the first thing worth reading — and often the best map to everything else.
Why the display code is legible
A display controller is configured once, at start-up, by a sequence of register writes carrying timing values. There is no way to compute them at run time and no reason to obfuscate them: they are the same numbers on every unit of the product.
| what is written | what it describes | how it is recognisable |
|---|---|---|
| horizontal timing | active pixels, front porch, back porch, sync width | four small integers in a narrow range, written consecutively |
| vertical timing | active lines, front porch, back porch, sync width | four smaller integers, same pattern |
| layer address | where the frame buffer starts | a value in a RAM region, aligned to a large boundary |
| pixel format | how bytes map to colours | one of a handful of small enumerated values |
| layer dimensions | window size and position | two pairs of integers matching the panel |
The first two rows are the giveaway. A block of eight consecutive small integers written to consecutive addresses is a timing configuration, and the sum of the horizontal four gives the panel’s total line length, while the sum of the vertical four gives the total number of lines. Multiply and divide by the pixel clock and the refresh rate falls out.
Reconstructing the panel from constants
The useful consequence is that a recovered image states the panel it was built for, without needing the hardware.
| derived quantity | how it comes out of the image | why a customer cares |
|---|---|---|
| visible resolution | the active pixel and active line counts | confirms which panel variant the product used |
| blanking intervals | the porch values | needed to drive a replacement panel |
| refresh rate | timing totals against the pixel clock | distinguishes a 60 Hz build from a 50 Hz one |
| interface width | lane count in the MIPI configuration | distinguishes a one-lane from a four-lane board |
The first row resolves a question that arises constantly on a repair: two panel variants with the same connector and different resolutions, and no marking on the assembly to say which is which. The image answers it, and it answers it for the specific unit rather than for the product family.
The frame buffer address as a memory map
The layer address is a single value, and it is disproportionately informative, because a frame buffer is large and has to be placed somewhere deliberate.
| address region | what it implies | consequence |
|---|---|---|
| internal SRAM, near the top of the largest block | a small panel, no external memory | the buffer competes with application data for space |
| internal SRAM, at a large aligned boundary | a design that reserved a fixed region | the reservation is visible in the rest of the image |
| external memory interface | an SDRAM or similar device on the board | the recovery has a second device to consider |
| several addresses for several layers | compositing, with more than one buffer active | the SRAM budget is the design’s central constraint |
The second row is the one to follow. A frame buffer placed at a round boundary implies a linker script or a manual reservation at exactly that boundary, and the region between the end of the buffer and the start of the next structure is usually where the application’s own memory begins. Reading outward from the frame buffer is faster than reading inward from the reset vector, because the frame buffer’s extent is known in advance.
Assets travel with the image
A display product contains non-code assets, and they survive in a form that is directly usable.
| asset | how it appears | what can be delivered |
|---|---|---|
| fonts | bitmaps or compressed glyphs with a width table | a regenerated font, usable in a new build |
| icons and images | raw pixel data, often run-length or palette encoded | image files |
| palette | a table of colour values | the exact colour set, which matters for brand consistency |
| strings | text in the product’s languages, often UTF encoded | a translation table |
The first two rows are frequently worth more to a customer than the code is. A product with a custom typeface and a set of icons has visual identity embedded in its firmware, and a rebuild without those assets produces something that looks wrong even if it functions correctly.
What the recovery has to state
The return set is the flash image, a disassembly annotated at the display initialisation, the derived panel parameters, the frame buffer addresses with their regions named, the extracted assets as separate files, and the configuration words that affect start-up.
| item | why it belongs in the report |
|---|---|
| derived resolution and refresh | lets the customer confirm the panel variant without opening the unit |
| frame buffer address and size | tells them how much memory the application really had |
| extracted fonts and icons | the part of the deliverable that a rebuild cannot substitute |
| interface lane count | decides whether a replacement board will work |
A related reading of the same generation, from the dual-core angle rather than the display angle, is at STM32H745 code recovery. The flash bank arrangement that decides which half of the array a given image came from is covered in STM32H743 flash recovery, and the encrypted external memory case that can hold either the code or the assets in STM32H725 heximal recovery. For a display-free design on the same family where none of this applies, STM32H723 heximal extraction is the plainer case.
FAQ
Can the panel resolution be determined without the hardware? Yes, from the timing constants in the display initialisation, which are written as plain values.
Are the fonts and icons recoverable separately? Usually yes. They are stored as data with a width or offset table, and both the data and the table survive.
Does a frame buffer in external memory change the job? It adds a device. The external memory has to be read as well, and on variants with decryption it may not be plaintext.
Conclusion
A display pipeline is configured with numbers that describe a physical object, and those numbers are stored as constants. That makes the graphics initialisation the most legible structure in the image, the fastest route to a memory map, and the source of the assets a rebuild cannot invent.
Posted in Recover Chip