APPLICATION NOTE

M16C Family Flash Over CAN

Implementation

Version 1.09. May, 2008

Table of Contents
1. Introduction to Flash over CAN ............................................................................................................................ 2

2. General description of the Flash over CAN concept ............................................................................................ 2

3. Location of CANloader and UserApp ................................................................................................................... 4

4. Reflash description .............................................................................................................................................. 4

5. Modifying the default FoCAN project ................................................................................................................... 5

6. Checksum protection against failed application reflash ....................................................................................... 7

7. Details on jumping between Canloader and UserApp ......................................................................................... 7

8. Debugging application Tips & hints...................................................................................................................... 8

8.1 Debugging with an E8 ..................................................................................................................................... 8

8.2 Unlock code..................................................................................................................................................... 8

8.3 Debug application stand alone ........................................................................................................................ 9

8.4 Tags................................................................................................................................................................. 9

9. Proposed next version of FoCAN ........................................................................................................................ 9

10. More Information ............................................................................................................................................. 9

REU05B0067-0109 FoCAN Application note May 2008 Page 1 of 11

 M16C Family Flash Over CAN

Application note

1. Introduction to Flash over CAN

’Flash over CAN’ or FoCAN is the ability to reprogram Renesas M16C family CAN MCU devices over a CAN
connection. This removes the need for standard debug, UART or serial interfaces to update the device
firmware. FoCAN uses a Systec ‘CANmodul’ (found in the RCDK8C - CAN D Kit) sniffer for the flash
programming HW interface. A Windows based Application, CAN_Download, provides a graphical interface
toprogram the MCU via the CAN network.

Figure 1. Flash over CAN may be used to reflash an application after a device is installed by giving the device
a unique programming ID.
FoCAN consists of a High-performance Embedded Workshop (HEW) workspace containing two
projects, CANloader and UserApp. CANloader and UserApp are independent of each other in that they are not
sensitive to any code or data remaps. Each project has a header so that the other one can read key
data; entry access points into the other program space, device and version IDs, data consistency checksum
values, and the security unlock code for flashing.
CANloader, the flashing project, is built to be located in the first flash block of the MCU. The user application is
free to occupy the other flash block(s). PC_Download sends programming commands and data frames thru
the sniffer, over CAN, to the MCU device. CANloader erases the user block(s) and reflashes the new user
application. After completion, the device reboots, checks for data consistency and enters the user application.
The application may be reflashed any time a user connects the PC to the bus and invokes the device’s proper
unlock code and reprogramming CAN ID. When this happens the application exits, reads the CANloader
header for entry address into CANloader, tells the PC it’s ready and UserApp is reflashed again.

2. General description of the Flash over CAN concept

FoCAN will work on any M16C family device with at least one CAN peripheral and internal flash memory. The
PC application, CAN_Download, sends programming command frames and application content data frames
via USB to the Systec CANmodul sniffer which sends them over CAN to the MCU. MCUs for which source
code for FoCAN is currently available are R8C/23, M16C/29 and M16C/6NK. The sample code can be found
at http://america.renesas.com. Click on Products / Connectivity Solutions / Industrial LIN/CAN Solutions / Industrial
CAN Solutions / Downloads.
The FoCAN firmware is written in one HEW workspace containing two projects; CANloader, and UserApp.
CANloader resides in the first flash memory block, or first two if block 0 is too small for that specific device.
CANloader erases the user application block(s) and then reflashes the UserApp firmware. The UserApp

firmware includes reflash exit code to transfer execution over to CANloader whenever reflashing is invoked.
This feature allows the device to enter reflash mode during normal execution of the application. UserApp is

REU05B0067-0109 FoCAN Application note May 2008 Page 2 of 11

 M16C Family Flash Over CAN

Application note

Flash o' CAN

Program flow

Reset CAN interrupts

CTRL_MSG_ID (201 default) = Flash control frame
Block 0: DATA_MSG_ID (200 default) = Flash user program data
hardware_setup()
can_init() etc.. All other CAN-IDs:
Calls user app's can_receive() routine
Control frame with data = unlockcode

Signal user application to exit

Previously successful
Enter canloader
user space (>block0) programming?
Application flash blocks 0-n erased!
(userid in user flash block == checksum (ex. 0x55AA)?

confirm with
CTRL_MSG_ID data = 0x55
Yes

Download (flash) If not in user area,

user program discard frames and report
Block 1-n: with incoming back with confirm with
user_main() . No - red LED CTRL_MSG_ID frames CTRL_MSG_ID data = 0xAA
.

CTRL_MSG_ID data signals 'file end'

Received signal to exit

RESET
Wait for for reflashing of user blocks
STOP

Use of RSK LEDs

GREEN = Userid detected OK
YELLOW = User application or user interrupt code
RED = Flash o' CAN communication LED
RED2 = Flash o' CAN; user application has exited, wait for restart
When reflashing; goes dark when RAM buffer is being written to flash.

Figure 3. Program flow of CANloader and application when flashing.

also where user application code is inserted by the linker. After reflash completes, the device reboots and
checks for data consistency before entering the application.
The default unlock code to reflash is 0x11, 0x11, 0x11, 0x11, 0x11, 0x11, 0x11, 0x11, 0x11. Note that this is
not the same as the unlock code used to unlock the device when accessing it via a serial flash programmer
e.g. the E8 debugger.

REU05B0067-0109 FoCAN Application note May 2008 Page 3 of 11

 M16C Family Flash Over CAN

Application note

If CAN_Download sends the correct control frame CAN-ID, the UserApp application reads from
canload_head.c in the CANloader section for an entry address to enter CANloader. CANloader then confirms
to the sniffer that it is ready and the application is reflashed.
Warning: No other interrupts should occur during reflash, as the MCU goes into and out of MCU E/W mode.

3. Location of CANloader and UserApp

Flash memory block 0 (and 1 if device block 0 is too small for that device) in the MCU contains the flashing
firmware CANloader. The user application may be mapped into any remaining block(s). The starting point
address of where the user application is located is specified by ‘APP_ADR’. See the HW manual’s section
‘Memory Map’ in chapter ‘Flash Memory’ and set the desired starting point APP_ADR of UserApp in your
sect30.inc and Flash_o_CAN.h. For example, in the M16C/6NK FoCAN firmware project, the user application
is set to start at E0000.

4. Reflash description
When the ‘Program’ button in the Windows PC application CAN_Download is pressed, commands will be sent
to the Systec sniffer to start downloading the user application code to the MCU flash. The first flash command
frame that is sent is the unlock code that the user enters right after the ‘Program’ button was pressed on the
PC. If the unlock code matches the value in the device’s CANloader header, programming is accepted, the flag
flashing_in_progress is set and the target device firmware enters into ‘Flash over CAN’ mode. CANloader then
confirms to PC_Download to proceed with the flash update. However, only CAN frames with CAN ID value
CTRL_MSG_ID are accepted and processed for reprogramming.
The CANloader firmware will idle when not processing CAN interrupts.
UserApp firmware is reflashed into the user flash memory blocks using EW1 mode. After the user blocks are
reflashed the device reboots.
After reboot, CANloader checks that the UserApp space was successfully flashed by verifying UserApps
memory using a checksum. The user mode interrupt vector in the UserApp scope is used if the device has
been successfully flashed. If CANloader does not calculate a matching checksum to what is stored in the App-
header, the device stays in CANloader and will wait until a new attempt is made to flash UserApp. See
Procedure as well as Tips & hints below for more information on successful programming.
To add a checksum to the application header you can use the default checksum algorithm or your own. This is
to be done when all application development activities are finished. See ‘Checksum protection against failed
application reflash’.
Download procedure
a. Program the RSK board with the CANloader project binary using HEW or FDT. See your RSK’s
Quick Start Guide for details on which MCU device to use, and how to connect and program the
device.

b. After programming CANloader, unplug your debugger and press reset or power cycle the device.
The bottom red LED should light up indicating the device is in CAN bootload mode waiting to be
programmed.

c. In HEW switch to the UserApp project.

d. Add your application under user_main(). To debug your application see ‘Debugging your application’
below.

e. Compile and link UserApp.

f. If you are not going to run CAN_Download from its folder within the source tree, copy the following
DLL-files from the “Flash over CAN/PC_Download” subfolder ‘DLL’ to the windows\system32 folder

REU05B0067-0109 FoCAN Application note May 2008 Page 4 of 11

 M16C Family Flash Over CAN

Application note

MFC42D.DLL
MFC042D.DLL
MSVCRTD.DLL
USBCAN32.DLL

g. Start CAN_Download.exe
The PC application CAN_Download.exe can be found in the “PC_Download” folder in the “Flash over
CAN” Hew workspace directory.

h. When CANloader is running on target RSK board, the CAN_Download.exe will send CAN control
messages with CAN-id CTRL_MSG_ID (0x201 in the example code) and subsequent program data
frames with the id DATA_MSG_ID (0x200).

i. Connect a Systec USB CANmodul sniffer to your PC and to CAN ch 0. For the 6NK that is the CAN
connectors closest to the E8 connector.

j. Inside CAN_Download, Press ‘CAN Setup’ and set to 500 kbaud. CAN Message ID should default to
200 in Standard.

k. Press ‘File Open’ and select the new application binary created from compiling UserApp.

l. The Unlock code is 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 but can be changed, see
variable unlockcode[8] located in the source code file canload_head.c.

m. Press Download. It takes a moment to erase the user blocks, then the LED will flash each time a
control frame arrives and the flash process continues.

n. When the flash process is complete and CANloader is sent the ‘file complete code’ from
PC_Download, the device is fully programmed.

o. After rebooting, the UserApp header is checked for a correct checksum or code before entering. This
header code would preferably contain a valid checksum generated via the process mentioned below in
‘Checksum protection against failed application reflash’.

5. Modifying the default FoCAN project

To adjust the sample project to your particular MCU variant there are a few code mapping issues to be looked
over. Most of the items you need to consider are your MCU’s memory size, and are in the file
flash_o_can.h, Each item of interest is commented separately in cursive.
CANloader header allocated flash address. There should be no reason to change this. The header should
reside in block 0 and it is put at the beginning, or ‘head’ of the CANloader firmware. If it is changed, the indirect
jump assembly instruction used when reading from the header must also be changed in UserApp. Note that all
defines default to integers unless casted with e.g. a trailing ‘ul’
#define CANLOADER_HEAD_ADR 0x0FE000ul //in flash_o_can.h
CANLOAD_HEAD_ADR .equ 0FE000h ;in sect30_canload.inc
CANloader program address. It is recommended that the CANloader be mapped directly after its header. This
is commented since by default one section is mapped after the previous if they are named consecutively in the
CANloader section setup (sect30_canload.inc) and since the exact location is not critical.
//#define CAN_LOADER_ADR 0x0FE100ul
UserApp header address. There should be no reason to move this. It is placed right up against the end of
Block 1, next to the CANloader’s header in block 0. If it is changed, the indirect jump assembly instruction used
when reading from the header must also be changed in CANloader, and also in sect30_canapp.inc.
#define APP_HEAD_ADR 0x0FDF00ul //in flash_o_can.h,
APP_HEAD_ADR .equ 0FDF00h ;in sect30_canapp.inc
UserApp code placed here. Set this address to the lowest address (highest block nr) according to your device
flash memory, as application code will by default be mapped after (higher address) APP_ADR. This value is

REU05B0067-0109 FoCAN Application note May 2008 Page 5 of 11

 M16C Family Flash Over CAN

Application note

set in the application section setup (sect30_canapp.inc)

APP_ADR .equ 0F0000h
This block number will depend on mcu size; the larger the flash the higher the number. UserApp must be in a
lower flash block number and the E8 debugger code in a higher block number (at lower address) or the
debugger will be erased. See ‘Memory Map’ section in your MCU’s HW-manual. If this is set to the maximum
block number, put the debugger kernel in block 0 when connecting with E8. See Debugging below.
#define HIGHEST_FLASH_BLOCK_TO_ERASE 8
This defines the scope of the checksum. Use it to cover the area you wish to check before entering. If it is long
it will take time to run the checksum algorithm. In later versions of FoCAN this is inot used, but calculated in
app header at compile (link) time.
#define APP_LENGTH 0x0DF00ul
Used IDs to reprogram this node. Data messages contain the user program, and control frames carry the
unlock code, specify length of programming data frames, carry programming acknowledgement frames etc.
#define DATA_MSG_ID 0x0200
#define CTRL_MSG_ID 0x0201

Define message box for control message responses. Do not set to 0 as this is the receive box.
#define CANBOX_TX_CNTRL_RSP 15
Optional size, must fit in RAM. If small, speed should presumably decrease. Check how much RAM your
device has before changing as it will be permanently allocated. An alternative is to use the stack for this by :
#define CANLOAD_FLASHING_BUFFER_SIZE 0x0200
Do not change. PC CAN_Downloader specific value.
#define MAX_CNTL_BATCH_LEN 0x20

CANloader UserApp

Figures 2a & 2b. Memory maps of projects CANloader (to the left) and UserApp for an M16C/6NK. The users
application code simply goes into ‘app_program’. For project CANloader, note the location of section
‘canload_head_FE’, and the fact that all following sections are in flash Block 0. For project UserApp, note the
location of section ‘app_program’ and the subsequent other sections for this project with app_header_FE at
the end of Block 1 right up against Block 0. This was done to keep the headers together and the code size
down.

REU05B0067-0109 FoCAN Application note May 2008 Page 6 of 11

 M16C Family Flash Over CAN

Application note

6. Checksum protection against failed application reflash

FoCAN has a data checksum byte in the control message frames (CTRL_MSG_ID frames), but this is
currently not used on the embedded side. The reason is because there already is a CRC field in all CAN
data frames. One can therefore say that it is already implemented in the CAN standard.
To prevent a failed application reflash should this occur due to some error when reflashing, the application
checksum protection shall be used. When finished developing UserApp’s application source code, a
checksum for the UserApp firmware can be calculated as follows:
1. Put a break in the application checksum calculation routine and restart, the application code will enter
the checksum calculation routine in the sample code when SW3 is pressed.
2. Make a note of the calculated checksum and write it to the application source code header for variable
app_check. Also make the calc-checksum routine of CANloader return a calculated checksum
instead of the default constant test value 0x55AA.

7. Details on jumping between Canloader and UserApp

Here follows a detailed explanation on how the source code is set up to enable code execution to jumps
between Canloader and UserApp.
Each project has a header so that the other one can read key data; entry access points into the other program
space, device and version IDs etc, (see header source files.) The headers’ locations in flash memory space
are specified by the flash_o_can.h file defines.
#define CANLOAD_HEAD_ADR 0xC000
...
#define APP_HEAD_ADR 0xBF00

Here is how we jump from CANloader to UserApp using an address specified inside the UserApp header: The
actual jump consists of two assembly lines of code. The first one clears register A0:
asm("mov.w #0,A0");

The next line does an indirect jump. It jumps to the address contained in [an offset+]A0, that is, to the
address contained in BF00+0.
asm("jmpi.a 0BF00h[A0]");

Notice the "contained in" above. The program will start executing from the address that is stored in BF00+0.
(This is not the address to jump to, but the location of the address in App-header). The next question is what
value is actually stored in BF00 (in the App-header)? This is determined at link time. The location of the
application start address is determined by the following lines in sect30_canapp.inc.
Notice the comments after ';'
;---------------------------------------------------------------
; Application ROM data and program section
;---------------------------------------------------------------
APP_HEAD_ADR .equ 0BF00h
.section program,CODE ;Tell the linker that we are now defining a new flash memory
;section named 'program' and it will contain actual program code.
.org APP_ADR ;This is the starting address where the code should reside.
.glb _app_mem_start ;This is just telling the linker to first of all place a label
_app_mem_start: ;'_app_mem_start' at the beginning of the section.

The next piece of the puzzle is filling the App-header at link time with the values we need. Go to app_head.c:

REU05B0067-0109 FoCAN Application note May 2008 Page 7 of 11

 M16C Family Flash Over CAN

Application note

0. #pragma SECTION rom app_header

1. const uint32 app_entry_addr = (uint32) &app_entry;
2. const uint8 app_id[0x10] = "APPLIC_ID_123\0"; // 0x10=16 bytes reserved
3. const uint16 app_check = 0x55AA;//0x73B8; //0x55AA=testing value
4. const uint8 * const app_mem_start_addr = &app_mem_start;
5. const uint16 app_length = (const uint16) ((uint8 const *)&app_entry_addr - APP_ADR);

The lines were numbered for reference here:

0. The header itself is located at the end of the Userapp area. Its place is specified in sect30_canapp.inc
(search for 'app_header').
1. We want the address of where to execute when jumping into UserApp. This would be right at the
reset address. See ncrt0_canapp.a30. Note that this is not at APP_ADR because the first code to execute in
time is not necessarily the code right at the beginning of user memory.
4. This 4th item of the header contains the actual start address in flash of all User Application code. Its value
will be APP_ADR. See explanation for sect30_canapp.inc above. (“.org APP_ADR” etc above.)

8. Debugging application Tips & hints

8.1 Debugging with an E8

When debugging with an E8: If your application uses all available memory blocks (it cannot use Block 0 where
CANloader is) you must in the dialog box for E8 place the target debug kernel code in block 0 above canloader
at a higher address. See the mapfile for free space in block 0. By default most FoCAN UserApp sample code
uses all blocks except Block 0. Here is an example using the M16C/29.

Figure: You can place the target debug kernel code in block 0 above canloader at a higher address to leave all
of UserApp free for your code. See the mapfile for free space in block 0.

8.2 Unlock code

The programming ID code is shown in the confirmation window when you flash the device!
The default unlock code for project CANloader connecting with E8 (not for reflashing over CAN) is
00000000000000h, or 0xFFFFFFFFFFFFFFh.

REU05B0067-0109 FoCAN Application note May 2008 Page 8 of 11

 M16C Family Flash Over CAN

Application note

If the default value was not used, and you cannot remember the unlock code, read the CANloader.mot file that
you used to program the device with, at the ID code addresses. These addresses are found in your MCU HW
manual. It will specify at what addresses the ID code values lie.
Example; In a certain project using the R8C/23 one could read the following ID code values by reading the mot
file at the addresses in the second column:
ID byte Address Value read
ID1 FFDF 00
ID2 FFE3 00
ID3 FFE8 00
ID4 FFEF 00
ID5 FFF3 00
ID6 FFF7 00
ID7 FFFB FF
In this case, use the ID-code 000000000000FF to unlock the device.
Tip: Use the power supply from E8 if there are problems unlocking.

8.3 Debug application stand alone

You can debug your application with the E8 debugger standalone without CANloader. That way CANloader
does not have to be downloaded when debugging. In this case uncomment the line
DEBUG_APP .equ 1
in sect30_canapp.inc. The reset vector now causes the MCU to start at the Application memory range
bypassing the FoCAN code. Also uncomment
#define DEBUG_APP 1
in flash_o_can.h if you want to use or add debug code.

8.4 Tags

It is possible to search for where modifications have been made to original device .a30 and .inc startup files.
To see the places in the startup code that have been modified to run the FoCAN concept, search for the
character ‘$’ in all the source files.

9. Proposed next version of FoCAN

Today each node is individually accessible for reprogramming in-network using a unique CAN ID, but the
number of standard IDs is only 2048 and there is no simple mechanism to program each product with an
individual programming CAN ID. Adding a mechanism to increment and add a Device Access Code to each
devices software image without having to rebuild the code has been suggested. This DAC would then be put
on a sticker onto the product. The PC application CAN_Download would then be changed to first ask the user
for which DAC number (Which device on a CAN network) to access. CAN_Download would then ask the
nodes in the network if such an ID exists. The device with the matching DAC would then unlock its
programming mechanism and acknowledge the message whereafter the user can enter the unlock code etc
and the programming is proceeded as it is today.
Change the current application checksum protection functionality to instead use a post build phase – that is,
add the checksum after compile/build instead of as today where it is entered before compile time.

10. More Information

a. CAN MCUs
Devices which can use this concept are primarily M32C/8x, M16C/6Nx, M16C/1N, M16C/29,
R8C/23. FoCAN software already exists for some of these devices. See item b.
b. See the CAN download page at http://america.renesas.com/CAN. Click on ‘Downloads’.

REU05B0067-0109 FoCAN Application note May 2008 Page 9 of 11

 M16C Family Flash Over CAN

Application note

c. E-mail
techsupport.rta@renesas.com

d. Renesas Technology Corporation Semiconductor Home Page

http://www.renesas.com

e. CAN Specification Version 2.0. 1991, Robert Bosch GmbH

f. IEC standards 118981-5.

REU05B0067-0109 FoCAN Application note May 2008 Page 10 of 11

 M16C Family Flash Over CAN

Application note

Keep safety first in your circuit designs!

• Renesas Technology Corporation puts the maximum effort into making semiconductor products better and
more reliable, but there is always the possibility that trouble may occur with them. Trouble with
semiconductors may lead to personal injury, fire or property damage. Remember to give due consideration
to safety when making your circuit designs, with appropriate measures such as (i) placement of substitutive,
auxiliary circuits, (ii) use of nonflammable material or (iii) prevention against any malfunction or mishap.

Notes regarding these materials

• These materials are intended as a reference to assist our customers in the selection of the Renesas
Technology Corporation product best suited to the customer’s application; they do not convey any license
under any intellectual property rights, or any other rights, belonging to Renesas Technology Corporation or
a third party.
• Renesas Technology Corporation assumes no responsibility for any damage, or infringement of any third-
party’s rights, originating in the use of any product data, diagrams, charts, programs, algorithms, or circuit
application examples contained in these materials.
• All information contained in these materials, including product data, diagrams, charts, programs and
algorithms represents information on products at the time of publication of these materials, and are subject
to change by Renesas Technology Corporation without notice due to product improvements or other
reasons. It is therefore recommended that customers contact Renesas Technology Corporation or an
authorized Renesas Technology Corporation product distributor for the latest product information before
purchasing a product listed herein.
• The information described here may contain technical inaccuracies or typographical errors.
• Renesas Technology Corporation assumes no responsibility for any damage, liability, or other loss rising
from these inaccuracies or errors.
• Please also pay attention to information published by Renesas Technology Corporation by various means,
including the Renesas Technology Corporation Semiconductor home page (http://www.renesas.com).
• When using any or all of the information contained in these materials, including product data, diagrams,
charts, programs, and algorithms, please be sure to evaluate all information as a total system before
making a final decision on the applicability of the information and products. Renesas Technology
Corporation assumes no responsibility for any damage, liability or other loss resulting from the information
contained herein.
• Renesas Technology Corporation semiconductors are not designed or manufactured for use in a device or
system that is used under circumstances in which human life is potentially at stake. Please contact
Renesas Technology Corporation or an authorized Renesas Technology Corporation product distributor
when considering the use of a product contained herein for any specific purposes, such as apparatus or
systems for transportation, vehicular, medical, aerospace, nuclear, or undersea repeater use.
• The prior written approval of Renesas Technology Corporation is necessary to reprint or reproduce in whole
or in part these materials.
• If these products or technologies are subject to the Japanese export control restrictions, they must be
exported under a license from the Japanese government and cannot be imported into a country other than
the approved destination.
• Any diversion or re-export contrary to the export control laws and regulations of Japan and/or the country of
destination is prohibited.
• Please contact Renesas Technology Corporation for further details on these materials or the products
contained therein.

© 2007. Renesas Technology Corp., All rights reserved.

REU05B0067-0109 FoCAN Application note May 2008 Page 11 of 11