STM32F769: Seven Timing Numbers That Describe a Memory Chip You Cannot See
November 27th, 2010 | 
Author: A recovery request usually names one device. On a board built around this part, the firmware may be spread across three: the microcontroller, a serial flash holding the application image, and a parallel memory holding everything that did not fit — frame buffers, sample buffers, and sometimes the code itself.
The third device is the one that gets overlooked, because it is not where anyone expects firmware to live. It is also the one that can be described most precisely from inside the image, because the controller that drives it is configured by software, and that configuration is a compressed description of the memory part.
What the controller has to be told
Before the external memory can be used, the program writes a geometry word and two timing words. The geometry says how the part is organised; the timing says how slow it is.
| field | what it declares | typical values |
|---|---|---|
| number of column address bits | columns per row | eight, nine, ten or eleven |
| number of row address bits | rows | eleven, twelve or thirteen |
| memory width | data bus width | eight, sixteen or thirty-two bits |
| internal bank count | whether the part has two or four banks | two or four |
| column address strobe latency | clock cycles from command to data | two or three |
| read burst and write burst mode | whether bursts are single or sequential | usually sequential |
Those six fields together describe the addressable capacity, and the arithmetic is direct: rows times columns times width times internal banks. A part with thirteen row bits, ten column bits, a sixteen-bit bus and four internal banks holds sixty-four million bits of storage organised as four million sixteen-bit words. That number either matches the device on the board or it does not, and if it does not, the configuration came from a different hardware revision.
The timing words
The timing registers hold the values that describe how the memory responds, expressed in controller clock cycles.
| parameter | what it constrains | what a large value suggests |
|---|---|---|
| row address strobe to column address strobe delay | how quickly a second access in the same row can begin | a slower part, or a slower clock |
| row precharge delay | time to close a row | likewise |
| row active time | minimum time a row stays open | older or larger geometry |
| row cycle time | row-to-row access | the dominant limit for scattered access |
| exit self-refresh to active | recovery from low power | a part with a long wake-up |
| mode register set to active | initialisation | rarely discriminating |
| write recovery time | time after a write before precharge | distinguishes faster parts from slower ones |
Individual values are not a fingerprint. The set of them is: a design configures the controller for the exact part it was built with, and the ratios between the parameters follow the part’s speed grade. A controller configured for a fast part on a board that now carries a slower one will work until the temperature rises, and the failure will present as random corruption that the customer attributes to the firmware.
Why code ends up out there
Executing from external memory is possible on this family, and it is a rational choice when the application is large and the internal array is not. What matters for a recovery is that the decision leaves a signature.
| signature in the internal image | what it means |
|---|---|
| controller initialisation before any large allocation | the design depends on external memory from early in startup |
| a copy loop with a source in the serial-flash region and a destination in the external memory region | the application is staged through two external devices |
| a jump to an address in the external memory range | execution continues outside the chip |
| a linker script boundary at the end of the internal array with a large vector table offset | the vector table was relocated |
The third row is the decisive one. Once execution continues outside the die, the internal dump is a boot stage and the external device holds the code that does the work — which is the same conclusion as on the value-line member, reached from a different direction, and covered in STM32F750 flash recovery.
Reading the external part
Three approaches, ordered by how much they depend on the firmware working.
| approach | how | reliability |
|---|---|---|
| through the controller, with the device running | read the memory-mapped range with the processor halted | high, if the controller is initialised and protection permits |
| through the controller, with a debugger writing the initialisation | reproduce the configuration, then read | high, but the configuration has to be correct first |
| directly from the memory device | connect to the part and read it as it is | highest, and independent of the firmware entirely |
The second is the one that most benches use and the one that produces the most interesting failures, because reproducing the configuration requires knowing the timing values exactly, and a controller configured with slightly wrong timings reads plausible data that is occasionally wrong. The third is slower and requires access to the board, and it removes the whole class of doubt.
When the readings disagree with the marking
A board whose controller is configured for a different part than the one fitted is not rare. It happens after a component substitution during a shortage, after a board revision that changed supplier, and after a repair in which the memory device was replaced with the nearest available equivalent.
The symptom pattern is distinctive. Reads through the controller succeed and every so often return a value that fails a checksum. The failure rate rises with temperature and with access speed. A direct read of the device returns correct data every time. That combination — intermittent through the controller, perfect directly — is the signature of a timing mismatch rather than a bad memory.
| symptom | likely cause |
|---|---|
| intermittent single-word errors that scale with temperature | timing values too aggressive for the fitted part |
| reads that work at low clock and fail at full speed | same |
| a geometry that implies a larger part than is fitted | configuration left from another board revision |
| data correct through the controller and correct directly | no fault; the earlier errors were elsewhere |
What the report should state
State the geometry as decoded, with the capacity the arithmetic produces. State the timing set and whether it is consistent with the part identification. State whether execution continues into external memory, and if so at what address. And state whether the external device was read directly or through the controller, because the two answers carry different confidence.
The banked internal array that sits alongside this external memory, and the boundary that falls in the middle of it, is covered in STM32F767 firmware recovery. The cache behaviour that decides whether a read of a buffer is current is in STM32F746 software recovery, and the case where the external device holds ciphertext rather than plaintext is in STM32H725 heximal recovery.
FAQ
Can the external memory be read without desoldering? Usually, either through the controller with the device running or by halting the core and taking over the controller. Both depend on the firmware not having protected the region.
Does a flat internal dump include the external memory? No. It is a separate device with a separate address range and a separate read.
Is the timing configuration reliable enough to identify the part? It narrows the candidates to a speed grade and a geometry. The package marking on the device itself settles it.
Conclusion
The external memory is the part of the board that a recovery plan most often forgets, and the controller configuration is the part of the image that describes it best. Geometry gives capacity, timing gives speed grade, and the presence of a jump into that range tells you the internal dump is only the beginning. Reading the registers costs nothing and prevents the most common incomplete delivery on this class of board.
Posted in Reverse Engineer Microcontroller