Useful documents for building own CAN bootloader

Document created by iggi Employee on Oct 22, 2014Last modified by Diana Batrlova on Sep 5, 2018
Version 6Show Document
  • View in full screen mode

Since there isn't a CAN based bootloader developed for S12X device family, here are some useful documents that might be of help for creating such bootloader:

 

- The AN3312 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.
https://www.nxp.com/docs/en/application-note/AN3312.pdf 

 

- 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.
https://www.nxp.com/docs/en/application-note/AN3034.pdf 

 

- 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.
https://www.nxp.com/docs/en/application-note/AN2295.pdf 
- Serial booloader for S12(X) family:
https://www.nxp.com/docs/en/application-note/AN4258.pdf 

 

With the information in these documents you can design your loader and plan how to solve the 5 main challenges of a loader application:

 

++Memory Protection++
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.

 

++Burning Flash++
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.

 

++Vector Redirection+
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.

 

++Data Interface++
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.

 

++Mode Selection++
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.

4 people found this helpful

Attachments

    Outcomes