R5F2136CFKFP uC

Renesas R5F2136CFKFP Microcontroller

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 = 128kB

• 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?

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.

• 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 I found 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.”