R5F2136CFKFP uC

Renesas R5F2136CFKFP Microcontroller

This is a work in progress, many things remain a mystery and I'll update the section as I learn more.

The microcontroller Kokusan Denki selected for the OSSA ECU is Renesas part number R5F2136CFKFP (part of the R8C family).  It is in a tiny 64-pin LQFP measuring only 10mm on a side with 128 KB of flash memory and 10 KB of RAM.  Renesas says it is particularly well suited for automotive use, and its wide operating temperature range is indicative of this.  The product is considered obsolete and has been superseded by the RL78 family. 

Wikipedia tells us, “The Renesas R8C is a 16-bit microcontroller that was developed as a smaller and cheaper version of the Renesas M16C.”  I was happy to read that, as I had a fair amount experience with the M16C in the late 1990s.  The M16C was designed by Mitsubishi, and my client said Apple Computer was buying them in large quantities (although I don't know for what). 

The part number breaks down as:

• R = Renesas Semiconductor

• Device Family: 5 = Renesas MCU

• Memory Type: F = Flash Memory

• Device Series: 21= RC8/tiny series

• Device Group: 36 = R8C/36 group

• ROM Capacity: C = 128 KB

• CAN, Data Flash: F = CAN Module but no Data Flash 

• Temperature Range: K = -40° C to 125° C

• Package Type: FP = LQFP

The fact that it has no Data Flash memory strikes me as strange.  Are the maps stored as constants in the code?  I also wonder how values like total operating time are stored in a non-volatile memory?  As far as I can determine, there is no memory external to the uC (non-volatile or otherwise).

Test Points

I've been pondering the purpose of what I presume to be test points on the PCB (see photo below).   At first, I thought they might provide a means to program a secure bootloader.  However, I can't find any documentation stating there is anything like a  JTAG port available.  The test points marked with their associated port names are as follows:

• Pin 30, Port 8_6 (P86 on silkscreen)

• Pin 31, Port 8_5 (P85 on silkscreen)

• Pin 32, Port 8_4 (P84 on silkscreen)

• Pin 33, Port 8_3 (P83 on silkscreen)

• Pin 34, Port 8_2 (P82 on silkscreen)

• Pin 35, Port 8_1 (P81 on silkscreen)

Secure Bootloader

Becasure new operating firmware (and maps) can be loaded to the OSSA ECU via a TTL serial port, I'm speculating that Kokusan Denki used a secure bootloader.  A secure bootloader allows distributing code in an encrypted form to prevent reverse-engineering.  Furthermore, it protects the chip from being debugged or reading the code back out.

I base this theory on the following observations:

• Flash programming performed via “serial mode 2” requires access to the uC's Reset (pin 6) and Mode (pin 3) lines which are not part of the Kokusan Denki serial interface.  Furthermore, as far as I can tell, none of the unused ECU pins go to either Mode or Rest (which would indicate the possibility of a special ECU programming fixture).

• The map files don't contain anything I can recognize as a map.

• Kokusan Denki apparently had no fear of the hardware being cloned and their firmware being copied.

The information below from Renesas supports this.

Renesas One Image Bootloader

The following quote is from Renesas documentation for their One Image Bootloader example, Rev. 1.00 dated September 17, 2020.

“The RL78 has a unique flash interface called the Flash Self-programming Library (FSP). 

[...] 

Note that a bootloader's design is completely custom.  Depending upon your projects requirements and limitations your bootloader will be different.  This module shows only one possible example, modifications can and should be made to adapt it to your specific requirements.” 

The photo below comes from the aforementioned document.  It clearly shows that only two signal lines (UART0 TXD and RXD) are needed to load firmware.

Again quoting Renesas, “The bootloader interfaces with the Flash Self-Programming Library to program new applications to the device.  The techniques used in this module can be adapted to any RL78 device that uses boot swap.” 

Data Transfer

The following information is specific to the file 20130727_OssaTr250i_Evo2.kds.  Linux reports the file size as 114696 bytes.  Using a hex editor, it can be seen that the offset of the last byte in the file is 0x1C007 (114695 decimal).  These two file length numbers agree when you consider that the first byte in the file is at offset 0x00 (not 0x01).

The Kokusan Denki program KWritePro_12 was used to send the aforementioned .KDS file to the ECU.  KWritePro_12 reported the file as being 113 kB.  (A KB in computer science is 1024 bytes.)

I used a serial port monitor to simultaneously monitor both sides (PC host and ECU) of the process.  The transfer record comprised approximately 19168, 16-byte lines.  This would be a total of approximately 306688 bytes.

Bytes to the ECU have a yellow background.  Bytes from the ECU have a white background.

Presumably, the first 0xD8 (216) bytes were used to establish communications and erase the flash.  Thereafter, for every 30 bytes sent to the ECU, an acknowledge byte of 0x45 (uppercase E ) was sent to the PC host.

Therefore, approximately 10,215 bytes of acknowledgement occurred in the 306688-byte total data exchange.  This equates to about 296,237 bytes having been sent to program the ECU.  This is a data "expansion" of about 2.58 times.  Recall that the microcontroller's total flash memory is 128 KB.  Obviously, there must be some overhead.  For reference, a Motorola S-Record is of the form "S", Type, Byte Count, Address, Data, Checksum.  (As an aside, I wonder if .KDS stands for Kokusan Denki S-Record?)

The flash programming operation takes about 26 seconds.  The end of the 113 kB file seems to transfer very quickly - as if the progress bar assumes a full 128 KB transfer.

I'm not sure why the Advanced Serial Port Monitor says the Baud Rate was 9600.  The transfer took place at 38.4 kbps. 

The most interesting thing is that the data that gets sent to the ECU is not the same data that's contained in the .KDS file.  Perhaps KWrite_Pro is performing some un-encryption?