CANopen communication
Some of the described features are always available, others can be activated about compiler defines included in the file <target>/bl_config.h.
CANopen network parameters
The CANopen network parameters are the CAN bit rate and the node-ID. These parameters can be configured application-specific by switches or loaded from nonvolatile memory. Because the configuration depends on the special device, Paulus provides the following functions:
<target>/<target>_init.c/getBitRate() to get the desired CAN bit rate
<target>/<target>_init.c/getNodeId() to get the desired node-ID
The node-ID can be configured by LSS additionally.
Paulus only supports 11 bit standard identifier.
NMT services
The NMT state machine according to /CiA-301/ is not supported by the Paulus bootloader completely because code size optimization. The Paulus bootloder remains in the NMT state PRE-OPERATIONAL after the boot-up.
NMT command | actions on Paulus |
Reset node | change into the NMT state Reset Application to re-start Paulus |
Reset communication | activate a new node-Id changed by LSS, reset SDO communication and send boot-up message, but a new CAN bit rate is NOT activated |
Start remote node | ignore NMT command and remain in the NMT state PRE-OPERATIONAL |
Enter pre-operational | ignore NMT command |
Stop remote node | ignore NMT command and remain in the NMT state PRE-OPERATIONAL |
Table 1: NMT commands
The NMT command Reset node initiates a software reset. Normally this NMT command is applied after a successful firmware download to start the new application program, see chapter 2.9.2.
Figure 1 shows the function flow initiated by the NMT command Reset communication:
Figure 1: Reset Communication
SDO services
Paulus operates as SDO server and supports the following SDO transfer protocols:
SDO expedited transfer | yes |
SDO normal (segmented) transfer download upload |
yes no |
SDO block transfer | no |
Table 2: supported SDO services
Paulus supports the following SDO abort codes:
SDO abort code | description |
05030000h | A wrong toggle bit in the SDO request message was occurred. |
06010002h | It was attempted to write a read only object. The Heartbeat producer time in object 1017h is not writeable. |
06060000h | An error was occurred during the flashing of the data into the program flash memory. |
06070012h | The domain size in the SDO request exceeds the size of the domain object. |
08000000h | This abort code indicates: · an error during erasing the program flash memory · the receipt of an unsupported service request · the receipt of a SDO request with a wrong or not supported SDO protocol |
Table 3: SDO abort codes
Error control services
Paulus supports the following error control services:
boot-up message | yes |
Heartbeat producer | configurable |
Heartbeat consumer | no |
Node Guarding | no |
Table 4: supported error control services
The Heartbeat producer is activated by the compiler define BL_USE_HB in <target>/bl_config.h:
#define BL_USE_HB 1
The target-specific code for the Heartbeat generation must be available. Dependent on the target processor various implementations for the Heartbeat generation are possible:
counting loop located in the main-loop: This method is more imprecise but needs less resources.
hardware timer: This method is more exactly but needs more resources.
external generation
The Heartbeat producer time is set in the source code, i.e. the Heartbeat producer time can not be configured about the CANopen network. The actual value is indicated in object 1017h. The generation of the Heartbeat producer message requires the function <target>/<target>_init.c/timerTriggered().
Figure 2: program flow for the Heartbeat producer service
Emergency services
Paulus supports the following Emergency services:
Emergency producer | configurable |
Emergency consumer | no |
Table 5: supported Emergency services
The Emergency producer is activated by the compiler define BL_USE_EMCY in <target>/bl_config.h:
#define BL_USE_EMCY 1
The Emergency producer service is implemented with the following limitations:
The cob-ID of emergency producer message is set according to the pre-defined connection set, see /CiA-301/, and is fixed.
Object 1015h (inhibit_time_emcy) is not supported.
Object 1001h (error_register) is not adjusted.
Object 1003h (predefined error field) is not supported.
After sending the boot-up message, the bootloader can send an additional Emergency message. This is useful to signal that the bootloader program is running instead of the application program. This functionality can be activated about the compiler define BL_TXEMCY_AFTER_BOOTUP in <target>/bl_config.h:
#define BL_TXEMCY_AFTER_BOOTUP 1
The content of the first Emergency message is defined in the variable emcyErrMsg[EMCY_0] in the module bl_canopen.c. A send Emergency after an occurred CRC error is available in newer porting’s.
Emergency messages are transmitted by the function canMsgTransmit().
Example: canMsgTransmit(EMCY_COBID, &emcyErrMsg[EMCY_0]);
PDO services
PDO services are not supported.
CANopen Layer Setting Services (LSS)
Paulus supports the following LSS services:
LSS slave | yes |
LSS master | no |
LSS switch state global | yes |
LSS switch state selective | yes |
LSS configure node-ID | yes |
LSS configure bit timing parameter | yes |
LSS activate bit timing parameter | yes |
LSS store configuration | yes with manufacturer-specific memory functions |
LSS inquiry
|
no yes |
LSS identification | yes |
LSS fast scan | yes |
Table 6: supported LSS services
This functionality can be activated about the compiler define BL_USE_LSS in <target>/bl_config.h:
#define BL_USE_LSS 1
The activated LSS functionality can be configured by the following compiler-defines in <target>/bl_config.h:
#define BL_USE_LSS_STORE 1
The LSS service “store” is optional and is switched on by this compiler-define.
#define BL_START_IN_LSS_CONFIGURATION_MODE 1
The bootloader is in the state LSS/CONFIGURATION after start-up.
#define BL_AUTO_SEND_NONCONFIGURED_SLAVE 1
The bootloader transmits the LSS “identify non-configured slave” message after start-up automatically without a request from the LSS master. This message substitutes the boot-up message for unconfigured devices. Please note that this behavior is not specified in the /CiA-305/.
The LSS service “store configuration” is available to save the node-ID and CAN bit rate in the nonvolatile memory. The functions for the access on the nonvolatile memory are manufacturer-specific and have to be added in bl_user.c/usrLssInd().
The LSS service “activate bit timing parameters” shall be used to activate a new CAN bit rate in the complete CANopen network. The new CAN bit rate cannot be activated by Reset Communication.
Object dictionary
The object dictionary of Paulus includes the following objects:
index | sub-index | access right | description |
1000h | 0 | const | device type |
1001h | 0 | const | no error is indicated by this object |
1014h | 0 | const | EMCY cob-ID (see chapter 2.5) |
1017h | 0 | const | Heartbeat producer time (see chapter 2.4) |
1018h | 0 – 2 (4) | const | identity object (from Paulus v1.27 full object supports possible) |
1018h | 3 – 4 | const | identity object, only if LSS is active |
1F50h | 0 | const | number of elements |
1F50h | 1 | wo | object for firmware download of program number 1 |
1F51h | 0 | const | number of elements |
1F51h | 1 | rw | download command of program number 1 (see chapter 2.8.1) |
1F56h | 0 – 1 | ro | application software identification |
1F57h | 0 – 1 | ro | flash status identification (see chapter 2.8.3) |
Table 7: Paulus object dictionary
Object 1F51h: program control
Paulus supports the following program control commands:
value | description | |
write access | read access | |
00h | -- | -- |
01h | start application program | -- |
02h | -- | -- |
03h | erase the application program in the flash memory | -- |
04h – 7Fh | reserved | |
80h - FFh | no manufacturer-specific command is available |
Table 8: program control commands
Object 1F56h: application software identification
Depending on the implementation there is only strongly limited support for this object available. It is possible to read and identify the CRC sum of the flashed application. Since Paulus version 1.40 object value
is 00h for invalid or not available application software identification.
Object 1F57h: flash status identification
Paulus supports the following flash status information according to /CiA-302-3/:
0 | 0 | status ok |
1 | in progress | |
1-31 |
| not supported (exception: a value unequal 0 means unknown error during erasing/flashing occurred) |
Table 9: flash status
Download an application program
Every CAN interface on PC can be used as a client counterpart, e.g. a USB-CAN interface (CPC-USB) or a gateway according to /CiA-309-3/ (EtherCAN).
The downloading software has to support the CANopen SDO transfer of domain objects. Best results can be obtained by using standard CANopen configuration tools like the CANopen Device Monitor from port.
Download with program start by start command
The following steps have to be executed to download an application program and to start the application program:
erase the flash memory by writing the erase command (value 3) on object 1F51h/1
download the application program file and store the file in the flash memory by writing the file on object 1F50h/1
start the application program by writing the program control command
start application program (value 1) on object 1F51h/1 and check emergency messages
Download with program start by reset
The following steps have to be executed to download an application program and to start the application program:
erase the flash memory by writing the erase command (value 3) on object 1F51h/1
download the application program file and store the file in the flash memory by writing the file on object 1F50h/1
execute the NMT command
Reset node to start the application program and check emergency messages
The application program is only started when auto-start is activated by the compiler define BL_AUTO_START in <target>/bl_config.h:
#define BL_AUTO_START 1
Paulus remains running when the compiler define BL_AUTO_START is not set. In this case the application can only be started by the start command.
Change between Paulus and the application program
The application program can initiate a jump back into Paulus. The re-start behavior of Paulus is determined by a keyword stored in the shared RAM. The application program shall use a macro to set the keyword and to jump to Paulus:
APPL | BOOTLOADER_JUMP(APPL) | Paulus is re-started and does not start the application program. The application program has to be started by command. |
BOOT | BOOTLOADER_JUMP(BL) | auto-start is active: Paulus is re-started and starts the application program. auto-start is deactive: Paulus is re-started and the application program has to be started by command. |
Table 10: BOOTLOADER_JUMP macros
The macros are located in bl_interface.[ch].