Customizing CANopen for Use in an Automated Laboratory Instrument
by M. B. Simmonds, Quantum Design Inc. and
Olaf Pfeiffer, Embedded Systems Academy
This paper was written for and presented at the 8th international CAN Conference in Las Vegas in 2002
[ Background | Requirements | Default Connections | Emergencies | Update ]
Providing for Application Firmware Update Via CANopen
We need the capability to update a device's firmware by loading new executable code directly through the devices own CAN interface. This requirement creates an interesting challenge for the firmware architect since the CANopen stack is an integral part of the application firmware and must be compiled together with it. We have decided that the most reliable and robust method for implementing this capability is to have a "CANopen Loader" permanently available on the module. This minimal operating system only needs to provide a few services. It must be able to implement an SDO-Server download, it must be able to verify the checksum of the program it has downloaded, and it must be able to transfer command to the downloaded program. Once the new downloaded program initializes and begins execution; it completely replaces the loader and provides the code to implement a CANopen interface for any further communications.
We have two separate banks of Flash memory available on each module. One bank contains the CAN loader firmware in a write-protected area segment. The other bank is available for storing downloaded application code. When the device is first powered-up or after a hardware reset, program execution transfers to the loader program. The loader can verify that the currently stored application has the correct checksum as part of its initialization process.
When the loader starts, the node is in a special state not described within the CANopen specification. Entry into this mode is signaled by a Bootup Message with a node number that is offset from the actual node by a value of 0x20 (0x720+NodeID). This would normally not be a valid Bootup Message within our restricted pre-defined connection set where we only allow a range of NodeID's (1-31), so it can be interpreted as an entry into the "System State". It can receive data and report status via SDO, but it has no access to the application's Object Dictionary and cannot process any PDOs. If the checksum of the current application firmware is determined to be correct by the system code, the node can be sent into its normal "Preoperational" mode by sending the usual network command. Alternatively, new firmware can be downloaded by use of SDO writes. After the new firmware has been loaded, execution can be transferred over to it by bank-switching between the two memory blocks. After initialization, the "real" application sends a standard Bootup telegram and enters its Preoperational mode. By using bank switching we avoid having to re-map the interrupt vector table: a new table is automatically loaded in the operation.
Creating a Manufacturer's Device Profile
Our modules are not intended for use on CANopen networks apart from our own internal instrument bus. Therefore we are free to create our own device profile with a common set of dictionary entries in the range 0x6000 - 0x9FFF. According to the specification, non-standard device profiles should be indicated by a Device Profile Number of zero in the Device Type entry (0x1000) of the devices Communication Profile. The 16 high bits of this entry are available to specify "Additional Information". We will place a characteristic version number in this location so that our system software can distinguish between different revisions of our device profile.
Our device profile will provide a device-independent structure for accessing common information such as module temperatures, module voltages, firmware checksums, error registers, and diagnostic test results. SDO writes to a standardized dictionary entry will be used to command various levels of diagnostic tests.
Conclusions
Completely standardized CANopen would come remarkably close to filling the needs for our modularized instrumentation. We will use PDOs to report measurement results back to the master node in the PC. SDOs will be used to set or read parameters as well as to issue confirmed commands to the nodes. Our modification of the Default Connection Set, our expanded scope of the Emergency Object, our provision for CAN-Based firmware updates, and our customization of the Device Profile go a long way toward making this high-level protocol a perfect fit to our requirements.
Quantum Design
11578 Sorrento Valley Road
San Diego, CA 92121
www.qdusa.com
Michael B. Simmonds
P: (760) 926-8673
info@qdusa.com
Embedded Systems Academy
50 Airport Parkway
San Jose, CA 95110
www.esacademy.com
Olaf Pfeiffer
P: (408) 910-7899
info@esacademy.com
[ Background | Requirements | Default Connections | Emergencies | Update ]
© ESAcademy, 2002
All materials
provided 'as is'
see Disclaimer