The word heximal is this trade’s shorthand for an addressed text file, and the assumption behind it is that any addressed format will do. On an eight-bit part that assumption holds, because the entire address space fits in the record field. On an RX62T it does not, and the reason is architectural rather than cosmetic.

The RX places its reset vector in the last four bytes of the four-gigabyte address space. Every image therefore contains data at 0xFFFFFFFC — an address that requires thirty-two bits to express. A record format with sixteen-bit address fields cannot reach it. A tool that emits such records will either drop that data or fold it into a low address, and either outcome produces a file that loads without complaint and cannot boot.

The device is R5F562T7EDFF#V1: RX62T group, thirty-two-bit core with an FPU, two twelve-bit converter units, motor-control timer, and a version code after the hash that identifies a shipping configuration rather than a silicon variant.

Two formats, one question

Renesas tooling has historically produced S-records, which is why S3 is the normal output for this family. The trap is that S1 files are also common — they are the default for smaller parts — and some programming tools accept both without warning about which one they were given.

What happens when the top of the map is dropped

Three distinct failures appear, and they are worth separating because the repair differs.

The first is truncation. The tool writes records for consecutive addresses until the data runs out, and stops before the vector area. The file’s highest address is somewhere inside the flash. A loader that programs it leaves the top of the device erased, which on this architecture means a reset vector of all ones — an address that points outside the flash, so the device does nothing at all on power-up. This is the most common of the three and the least confusing to diagnose.

The second is wrap-around. A tool that masks addresses to sixteen bits turns 0xFFFFFFFC into 0xFFFC and writes the vector into the middle of the flash, overwriting code. The file is well-formed, the records are consecutive, and the damage is invisible until the code at that address is examined. This one is dangerous because it can also corrupt an otherwise good image during a conversion rather than a read.

The third is a silent split. Some converters emit an extended-address record for the upper region and then emit data records without resetting the base afterwards, so the bytes that follow land at addresses the loader no longer expects. Loaders differ in how they handle this. Half of them accept the file and produce an image with a hole.

What a correct file looks like

A correct S-record file for this part has four properties, all checkable with a text editor and a small script.

It contains S3 records for data, not S1. It contains a record whose address is 0xFFFFFFFC and whose four data bytes decode to a plausible flash address. Its record addresses are monotonically increasing within the data region, with an explicit jump at the top-of-map boundary rather than a wrap. And it ends with a termination record — S7 for a 32-bit file — carrying the entry point.

That last item is frequently missing and rarely noticed, because programmers that ignore it work fine and programmers that require it reject the file with an unhelpful message. Its absence is also a useful signal: a file with no termination record is usually a file produced by a converter rather than by a read.

Two outputs from one read

The professional habit on this device is to emit both the addressed file and the flat binary from a single buffer, and to treat the pair as one deliverable.

The reason is verification rather than convenience. Converting an S-record file to a binary is a lossless operation when the base is known, so the two files must agree byte for byte. If they do not, the conversion introduced the error rather than the read, and the diff points at the record where it happened. A supplier who delivers only one format has removed the customer’s ability to perform that check.

Alongside them belongs one line of text stating the base address, the highest address used, and the total byte count. On a part whose address space spans four gigabytes, “the file is complete” is not a meaningful claim unless those three numbers are stated.

The option area is in the file, and that is deliberate

The option-setting memory sits at the top of the same flash, so a full read returns it as ordinary data records just below the vector. That is convenient — protection state, watchdog configuration and reset behaviour arrive with the code — and it is also a hazard, because a loader that programs the whole file writes configuration as well as application.

A customer burning a file that includes the option area into a replacement device gets those settings copied, which is usually what they want. A customer burning the same file into a development board gets a device that behaves like the production unit, watchdog and all, which is usually not.

The remedy is a note, not a file edit: state which address range holds configuration rather than code, so the person doing the burning can decide whether to include it.

For the flat-file version of the same problem, R5F562T6BDFF binary covers what a format with no addresses cannot say. For the byte-order question that no record format expresses, R5F562T7BDFF code takes it apart. And for a Renesas part where the same record-format decision has to be made on an entirely different memory map, RH850 R7F7010303AFP heximal is the comparison.

FAQ

Can an S1 file be converted to S3 safely? Yes, if the data is intact — the conversion widens the address field and does not touch the bytes. It cannot recover data that was already dropped or wrapped.

Does the reset vector have to be in the file? It does if the file is meant to produce a bootable device. A file without it is an application image, not a firmware image.

Why do so many tools default to S1? Because the format dates from an era of sixteen-bit address spaces and the default was never changed. It is a legacy default, not a suitability judgement.

The short version

The vector lives at the top of a four-gigabyte map, so the file must use thirty-two-bit address records or it cannot carry the image. Check for S3 records, check for an address of 0xFFFFFFFC with a plausible value, check that there is no wrap, and emit a binary alongside so the pair can be diffed. Three of those four checks take seconds and catch nearly every container failure.

Comments are closed.