There is a version of this job that is about code and a version that is about behaviour. The R5F35L26KFE, being an 80-pin 125°C part with 128 KB of flash and a CAN controller, usually lands in the second category: the customer does not just want the hex, they want to know why the unit stops responding on the bus after ninety minutes at temperature.
Two Deliverables In One Job
The first is the merged image: ROM 1 from E0000h to FFFFFh, ROM 2 at 10000h to 13FFFh, both data flash blocks, and the option window. The second is a behaviour record, taken before the array is read, if the unit still runs. On a CAN design that record covers the message buffer layout in the 32-slot controller, the acceptance filter settings, and the baud timing registers.
Doing the behaviour record first matters because a read is non-destructive but a thermal soak is not. If the unit is going to fail at temperature, the failure should be captured while it is still repeatable, not after a bench session has moved the board around.
Array Facts
One hundred and twenty-eight kilobytes of program ROM 1 sit at E0000h upward. Twelve kilobytes of RAM at 00400h to 033FFh. Eight kilobytes of data flash in two 4 KB blocks at 0E000h. The reserved band from 14000h to DFFFFh returns a fixed pattern and should be checked as a sanity test on every read.
The Temperature Question
K-grade parts are qualified from -40 to 125°C, and the failure people send us is rarely a dead die – it is a part that works cold and misbehaves hot. Two causes dominate: a data flash constant written at end-of-line that drifts outside its intended window, and a firmware timing assumption that only breaks when the oscillator pulls. Both are visible if the dump includes the data flash blocks and the option bytes; neither is visible in a code-only dump.
Reading Without Damage
ROM code protect and the ID code check are both configuration. The array is not erased, not partially erased, and not rewritten during the process. A unit returned from a read still holds the same bytes it arrived with, and the report proves it with checksums taken before and after.
Timing Problems That Only Appear Hot
A controller that fails after ninety minutes at temperature usually has one of three causes: a constant in data flash that was written at end of line and drifts, a timing loop calibrated against the internal oscillator rather than the crystal, or a thermal model that assumes a heatsink the replacement does not have.
The first is visible in the dump. The second is visible in the clock configuration and in the reload values of the timers. The third is not in the firmware at all. Separating the three is the reason a behaviour record is taken before the array is read: it is the only evidence that distinguishes a code defect from a mechanical one.
Turnaround Realities
A clean board with accessible pads is a same-week job. A potted 125°C assembly is not, and the difference is inspection, not extraction. Quoting without a photograph produces either an optimistic number or an unnecessary margin.
Handover
Files: merged HEX, four region binaries, checksum sheet, and a configuration page. If a behaviour record was taken, it ships as a separate document with the register values and the conditions under which they were captured.
Send the unit with a note on the ambient temperature and how long it takes to fail. The contact form is the right place for that detail; packing guidance is on the services page. Related parts: R5F35L26JFE for the commercial grade, R5F35L23KFE for 96 KB at the same rating.