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.

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:

Table 2: supported SDO services

Paulus supports the following SDO abort codes:

 Table 3: SDO abort codes

Error control services

Paulus supports the following error control services:

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:

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:

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:

Table 7: Paulus object dictionary

Object 1F51h: program control

Paulus supports the following program control commands:

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.

Object 1F57h: flash status identification

Paulus supports the following flash status information according to /CiA-302-3/:

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:

1. erase the flash memory by writing the erase command (value 3) on object 1F51h/1

2. download the application program file and store the file in the flash memory by writing the file on object 1F50h/1

3. 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:

1. erase the flash memory by writing the erase command (value 3) on object 1F51h/1

2. download the application program file and store the file in the flash memory by writing the file on object 1F50h/1

3. 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:

Table 10: BOOTLOADER_JUMP macros

The macros are located in bl_interface.[ch].