Unfortunately, CAN based bootloader is not developed for this device family. We do not have a Bootloader implementation that uses CAN as the interface and that is targetted for the S12(X) devices. There is Serial Bootloader only for S12(X) microcontrollers.
Some useful documents that might help you creating this Boot Loader Application are mentioned below.
This is an application note of a BootLoader that uses CAN but it is targetted for our DSC family of devices. These devices have the FlexCAN module (the silicon that handles CAN Communications is different to the one in the MC9S08DZ60). However this document can be used as a reference on how to build a loader.
Following document explains how to use the msCAN module for communications. It provides basic examples on how to send and receive data through the port.
Next document provides the source code and documentation for an assembly-written Bootloader. This software loads the code through the serial port and burns it into flash. This document can help you understand the specific details of the bootloader implementation. This code is available for a lot of S08 families included the MC9S08DZ60 device.
Serial booloader for S12(X) family:
With the information in these documents you can design your loader and plan how to solve the 5 main challenges of a loader application:
The Boot Loader handles the non-volatile memory of the microcontroller. The developer must plan how much memory is needed for the loader and protect it. Memory protection provides a guideline of the final system memory organization. A section of memory is used for the loader and another section for the application. Applications that will be executed with a loader are affected by how the loader manages memory and interrupt vectors.
Programming and Erasing non-volatile memory requires special attention as the procedure must be executed in RAM. The process of handling NVM may vary between devices. We have source code that provides routines to write Flash and that solves the problem of executing in RAM.
Interrupt vectors should be shared between the application and the users code. Hardware vector redirection is supported by the microcontrollers but with some limitations. It is necessary to decide how vector redirection will be implemented. Software and hardware methods can be used to redirect vectors.
Different applications required different interfaces to receive s-record information. Serial Ports are used widely for this purpose although the bootloader implementation should allow exchanging interfaces in a simple way. For your case you want CAN interface. CAN frames support up to 8 bytes of data per frame. This requires the developer to fully design a protocol or a data structure mounted over the CAN frames to be able to send the complete frames to the device that will be reprogrammed.
The Boot Loader is the owner of the reset vector. Upon startup the Boot Loader should select if the User code will be executed or if the Boot Loader mode should execute. The applicaton determines the best way to select between User/Loader mode. It might be a simple GPIO or a CAN frame or any input that can be recognized by the application and Loader to be able to set the loader mode when needed.
Developing a loader is not easy, but hopefully this information will be of a great help.
I have a question. I got a CAN bootloader to work and I can download programs that are small in size. I cannot seem to download the program I need. I think the cause is it's too big. I'm using the S12GA240. I get the "S-Record out of range" error. I used AN4258 and converted the code to work with CAN. Any help would be greatly appreciated.
you need to convert the S-Record using the SRecCvt tool. The GUI comes with the AN4258SW zip file.
But the original GUI version does not include S12G240 device, so it's not featured in the drop-down list device selection.
In order to fix this, modify the DeviceInfo.dat file, located in SRecCvt folder, by adding the following text line:
The line above will allow the S12G240 device to appear in the SRecCvt-GUI device selection. Then you can convert the S-record file from Banked Input to Linear Output.
I tried this actually but it didn't work. I'm getting a lot of S1 records. Also tried to modify the S12G128 demo program that comes with the AN4258SW files but once the code get's large enough I get "Error: 1 - S-Record out of range" error. If I try to flash the converted files with the S1 records I get a "Error: 5 - Bad hex data".
Read in another forum post (https://community.freescale.com/thread/23215) about using SRecCvt to get the "8000-BFFF S-records to separate file and shift these to proper "page" using sreccvt with -of switch" but I can't run the command line SRecCvt, only the GUI one works. The command line one just opens and closes, does not stay open. Tried it on different computers with XP compability and even tried it on a machine that runs XP.
The file I'm trying to convert to flash the micro with via the bootloader is about 75kB, so it's quite large program. I been trying to resolve this issue for some time now, so any help would be greatly appreciated.
I've been in touch with iggi and he sent me your bootloader code. When debugging the bootloader, have you set a breakpoint at the point where the S-Record range error is reported and looked at the S-Record data that was received?
When I have written and debugged bootloaders, I generally try to narrow it down to a single S-Record that will cause the problem and create a file with nothing more than that single S-Record. I have the sending source (usually a terminal program) send that single line file, allow the bootloader to receive the entire line and then analyze the data that was received.
A "Bad hex data" error usually occurs when the bootloader receive routine drops a character and then receives a Carriage Return, Line Feed and/or the 'S' of the next S-Record when it was expecting ASCII Hex data. Again, have you set a breakpoint at the point where the Bad hex data error is reported and looked at the S-Record data that was received?
Hi Gordon, I have not tried to debug the single lines but I will try it. I assumed that the bad hex data error was created because of the S1 records (I start a new thread actually on this forum about this) because when I looked at the .S19 and the bootloader, I saw that once the bootloader receives a 'S' character it reads the next character and if it's not 9, 8, 7 or 2 it gives a error (maybe I'm wrong on this). My solution for now (not sure if it's a good one) is to select S12G128 as the derivative for the project. This solves the bad hex data error however when I try to use interrupts I get a S-Record out of range error. So now for now I'm not using interrupts and selecting my projects as S12G128 derivative. We are starting to put the bootloader into prototype sensors that we won't be able to change later, don't want to have a bad bootloader and have to update it later on. I will let you what I figure out by using the breakpoints. Thank you for the response, really appreciate it.
Looking at the RcvSRecord() function, if an S-Record other than S0, S9, S7, S8 or S2 is received, the 'continue' statement following the last 'else' causes the code to go to the top of the for(;;) loop and simply receive the next character. Essentially this just keeps receiving characters until the next 'S' character is received, ignoring the S-Record. Perhaps this is confusing the sender since an '*' character is not sent back for the ignored S-Record line.
I'm not sure what is causing the error when interrupts are enabled, except that when a Flash program or erase operation is in process, interrupts MUST be disabled if the interrupt vector table is in Flash because Flash cannot be read during program or erase operations. Though this generally causes the MCU to 'crash'.