dsPIC33xx

Porting Paulus on Microchip dsPIC33EPxx

File structure

After installation of Paulus the source code is stored in the file structure shown in Table 1 describes the contents.

File structure:

directory

description

/paulus_dsPIC33EPxx

project folder with all necessary MPLAB project files

/bootloader

target independent CANopen sources for Paulus

/eds

Design Tool project of Paulus with all generated files, e.g. the EDS file and documentation files

/dsPIC33EPxx/

Target-specific sources of Paulus, e.g. CAN-driver, CPU- initialization, flash-service. Some functions used supporting services from Microchip Corporation e.g flash-service.

/ dsPIC33EPxx /

dspic33epxx_flash.[ch]

target-specific flash routines

/ dsPIC33EPxx /

dspic33epxx_can.[ch]

CAN routines

/ dsPIC33EPxx /

dspic33epxx_init.c

CPU initialization

/ dsPIC33EPxx /environ.h

header file for the environment definition

/ dsPIC33EPxx /bl_config.h

Paulus configuration file

/example

example application with a CANopen slave project (s1)

/tools

checksum generator tools for Paulus

main.c

main loop of Paulus

Table 1: File structure

The initialization of the CAN controller is done in module dsPIC33EPxx / dsPIC33EPxx_can.c.

In module dsPIC33EPxx / dsPIC33EPxx_init.c the I/O pins for the CAN interface have to be initialized.

In module dsPIC33EPxx / dsPIC33EPxx_init.c there must be the functions getBitRate() and getNodeId() available. Usually the CANopen network parameters are provided by reading jumpers or by loading from flash memory.

Development environment

Paulus on the platform of Microchip dsPIC33EPxx was developed with the MPLABX IDE v5.05 with XC16 compiler v1.35. The hardware environment is a Microchip Explorer16 Board with dsPIC33EP512MU810 as target CPU (PIM modul).

Paulus configuration

In general the initialization function initializes only the absolutely necessary peripherals like clock system, CAN controller, memory management as needed by Paulus and a timer for Heartbeat or LSS. Nevertheless, there might be situations where it makes sense that Paulus initializes other functionalities which are later used by the application as well. As an example consider the serial interface for debug messages.

CAN bit rate

The CAN bit rate is coded by the index of the CAN bit timing table according to /CiA-305/. The index of the default CAN bit rate is specified about the compiler-define BITRATE_INDEX_<bit_rate> in /dsPIC33EPxx/bl_config.h:

#define BL_USED_BITRATE_INDEX   BITRATE_INDEX_125K

The default CAN bit rate is 125 kbit/s and can be changed by LSS services. The LSS services are described in /Paulus_man/ and base on /CiA-305/. The supported CAN bit rates are depending on the clock of the CAN controller and are listed in / dsPIC33EPxx / dsPIC33EPxx_can.c. The value FFh for segment3 marks unsupported CAN bit rates. The clock for the activation of the CAN bit rate is generated by Timer1 with a period of 5 ms.

Heartbeat producer

Timer1 is also used for the generation of Heartbeat producer messages.

Debug output

By the compiler-define DEBUG a debug output can be activated about the serial interface usart1. The compiler-define is set in file /dsPIC33EPxx/bl_config.h:

#define DEBUG 1

In general the initialization function will initialize only the absolutely necessary peripherals like clock system, CAN controller, memory management as needed by Paulus. Nevertheless, there might be situations where it makes sense that Paulus initializes other functionalities which are later used by the application as well. As an example consider the serial interface for debug messages.

Generating application software

The application software consists of an application header and an application program.

The application program has to be prepared for download by the following steps:

  • build the application program in binary format

  • calculate the CRC of the application program, build the application header and generate the application software to download

  • configure the start address of the application software in Paulus

objcopy

The creation of the binary image is done out of the iHex-file from MPLABX-IDE. It is recommended not to compile a fuse bit configuration into the application. The fuse bit configuration of Paulus is used. The fuse bit configuration within the application is therefore dispensable and would enlarge the binary image significantly. The program objcopy can be used to create a binary from the iHex-file.

The binary for the application program s1_appl.bin is generated about console:

C:\jsc\Paulus_dsPIC33EPxx\Paulus\software\tools>objcopy -I ihex -O binary --gap-fill 0xFF s1_appl.hex s1_appl.bin Command reference: -I ihex Inputformat ihex -O binary Outputformat binary −−gap-fill 0xFF fill gaps with 0xFF

Paulus checksum

The program paulus_cksum calculates the CRC checksum of the binary application program generates the application header and stores the application header and the application program in a new file. This file can be loaded in the device by Paulus.

Unused bytes in the application header are set to 0x00 with the dsPIC33EPxx. The length of the application header is 256 bytes.

The download file for the application program s1_appl_download.bin is generated about console:

C:\jsc\Paulus_dsPIC33EPxx\Paulus\software\tools>paulus_cksum -v -P -C –a 0x400 -b 0x7000 -x 0x3800 -O s1_appl_download.bin s1_appl.bin reduce Flash end to file end: 0x000106ec reduce EndAddr to the Flash end 0x000106eb address - crc: 0x00000400, start: 0x00007000, end: 0x000106eb, exec 0x00003800 Flash end: 0x000106ec out: >s1_appl.download< input: >s1_appl.bin< create dsPic image (only CRC part) new addresses from 0x00000000 to 0x00007130 calc CRC from 0x00000000 to 0x00007130 size: 0x00007131, crc: 0x05b8 Writing Appl. to >s1_appl_download.bin<: length: 28977/0x7131, crc: 0x05b8, execadr: 0x00003800 Command reference: -P dsPic33 -C CANopen CRC -a CRC Block address (byte address) -b Application start address (byte address) -F Flash end address (byte address) -O output file (incl appl.bin) == complete domain -x Entry point (without conversion) -v verbose

The Flash end address is required to ignore the Configuration bits, if this bits are included in the binary. The used addresses are byte addresses, the common Word-addresses of dsPIC33EPxx have to be duplicated, therefore.

Besides checking the CRC Paulus checks also the size of the application header. A size of 0 is invalid. An application may destroy the ’valid’ information by overwriting the size with 0. That is always possible on the Microchip dsPIC33EPxx FLASH, because the byte content is 0xFF after erasing.

More detailed information from this tool can find in /Paulus_CRC/.

The batch script create_image.bat organizes these previously described steps.

Start address

It is important that the start address of the application software in the flash memory and the information in the Paulus configuration in dsPIC33EPxx / dsPIC33epxx_flash.h are identical. The application software is stored as a separate program in the flash memory additionally to the bootloader program. Therefore the application software is flashed to:

#define FLASH_PROGRAM_REAL_START_ADR   0x003800

The length of the application header is 256 byte. The program start of the application is at address (FLASH_PROGRAM_REAL_START_ADR). The shifted jump address of the application must be a multiple of 0x800. The minimal step for an erase operation is 0x800 (erase page size). Therefore, the application jump-in address is set to 0x003800 it’s identical with the FLASH_PROGRAM_REAL_START_ADR.

Memory

Shared RAM

The shared RAM for data exchange between bootloader and application starts at address 0x1100. The size of the shared RAM is specified in <target>/bl_interface.h by the compiler-define BL_JUMPCODE_SIZE. The shared memory is installed in <target>/bl_interface.h as follow:

UNSIGNED8 jumpcode[16] __attribute__((section(".pbss"), address(0x1100)));

The keyword for the re-start of the application program is set in byte 0-3 of jumpcode. Paulus uses the keyword “APPL” or “BOOT” to start the application program, see /Paulus_man/.

Flash

The total size of the dsPIC33EP512x user program flash is 512Kb. The current implementation of Paulus occupies a memory area of 20Kb from this. Therefore 492Kb flash memory area is available for the application software.

After a CPU reset the program makes a jump into Paulus to make sure it starts there and carries out the application checksum.

The flash area for configuration data of Paulus is located at flash address 0x003000 and following. On this address and the following Paulus stores the node-ID and the CAN bit rate index during the execution of the LSS service “LSS store configuration“. The addresses are configurable in <target>/bl_interface.h:

#define FLASH_ADDRESS_NODEID           0x003000

#define FLASH_ADDRESS_BITRATE_INDEX    0x003001

After the next re-start Paulus read this flash addresses, saved the values in an own RAM variables and uses this node-ID and this CAN bit rate index for communication. The new CAN bit rate cannot be activated by NMT-Command Reset Application. If the LSS services are not used, Paulus uses the node-ID and CAN bit rate index configured in dsPIC33EPxx / bl_config.h.

Example application

This example has included source files bl_interface.c, bl_interface.h from bootloader. The application program can request an update by jumping back into Paulus by writing of the program control command start application program (value 1) on object 1F51h/1. The application program calls the macro BOOTLOADER_JUMP(APPL). This call is implemented in usr_301.c /sdoWrInd(). The application program stores the keyword “APPL” in the shared RAM and jumps into Paulus. Paulus is re-started and stays running until the application program is started by command.

References

/CiA-305/

CANopen Layer Setting Services and Protocols, CiA

/Paulus_CRC/

manual “Paulus Checksum Tool”, see file  tools/manual_cksum.pdf

/Paulus_man/

manual “Paulus User Manual”, see file  UserMan_Paulus_Bootloader_e.pdf

Table 2: References