HW wiki - User contributions [en]

Boa5200 HOWTO

2007-11-04T15:53:18Z

Hamacl1: /* SDO and PDO example */

==Introduction==
This document describes how to install and setup Linux and development environment for BOA5200 board.
Assume that you have a development machine (your PC) that you use for development and building your applications which you consequently want to get running and test on BOA5200.

==Serial line setting==
The easiest way to communicate with the board ,when there is no OS and remote shell running on it, is over serial line. Recommended serial communication program is minicom. Setup minicom as follows:

Baud Rate – 38400

Bits - 8

Parity – N

Stop Bits - 1

Hardware Flow Control:- No

Software Flow Control:- No

After the setup you will see Redboot> command prompt. Here you can enter Redboot`s commands.
Redboot is a simple boot manager bulit upon eCos real-time OS. For more details , see http://ecos.sourceware.org/ecos/docs-latest/redboot/redboot-guide.html.

==DHCP server setup==
Redboot supports BOOTP protocol which means that it is able to get network information(IP,netmask,gateway IP address,etc.) from DHCP server(provides BOOTP besides DHCP protocol). Install dhcp server (on debian: apt-get install dhcpd) on your development machine. Example of my dhcp configuration file /etc/dhcpd.conf:
# I have two ethernet interfaces:
# eth0 - Internet
# eth1 - connection to BOA5200 (IP= 192.168.10.1)
# I do not want to progate infos to 147.32.0.0 subnetwork
subnet 147.32.0.0 netmask 255.255.0.0 {
}

# private subnetwork
subnet 192.168.10.0 netmask 255.255.255.0 {
option broadcast-address 192.168.10.255;
option routers 192.168.10.1;
option subnet-mask 255.255.255.0;
default-lease-time 600;
max-lease-time 7200;

# settings for BOA5200
host BOA5200 {
hardware ethernet 00:08:f1:11:22:33;
fixed-address 192.168.10.2;
}
}

Start dhcp server and reboot the board. After booting it has assigned IP, netmask and gateway address:
+PHY0: AMD AM79C874
FEC eth0: 100Mb/Full Duplex
Ethernet eth0: MAC address 00:08:f1:11:22:33
IP: 192.168.10.2/255.255.255.0, Gateway: 192.168.10.1
Default server: 192.168.10.1

==TFTP server setup==
Redboot is able to load file from remote tftp server into memory. Tftp server is lanuched by inetd daemon when a new
connection comes.
Therefore add the following line into /etc/inetd.conf :
tftp dgram udp wait nobody /usr/sbin/tcpd /usr/sbin/in.tftpd

Default tftp root directory is /tftpboot. You can change it by calling in.tftpd with specified directory as a parameter.

===Alternative way for Ubuntu based distro===

1. Install tftpd and related packages.
sudo apt-get install xinetd tftpd tftp

2. Create /etc/xinetd.d/tftp and put this entry:

service tftp
{
protocol = udp
port = 69
socket_type = dgram
wait = yes
user = nobody
server = /usr/sbin/in.tftpd
server_args = /tftpboot
disable = no
}

3. Make /tftpboot directory

sudo mkdir /tftpboot
sudo chmod -R 777 /tftpboot
sudo chown -R nobody /tftpboot

4. Start tftpd through xinetd

sudo /etc/init.d/xinetd start

see [[http://www.example.com Installing and setting TFTPD in Ubuntu]]

==Tool chain==
Toolchain(gcc, ld, ...) for MPC5200 can be downloaded from ftp://rtime.felk.cvut.cz/MPC5200/gcc-powerpc-603e-linux-gnu-4.1.1-bin.tar.gz
Unpack the archive:

cd /
tar xvzf gcc-powerpc-603e-linux-gnu-4.1.1-bin.tar.gz

You can also create a debian package from archive and then install the package:
alien --to-deb gcc-powerpc-603e-linux-gnu-4.1.1-bin.tar.gz
Note: If you are not root, use fakeroot to run the command.

==Applying kernel patches==
It is recommended to use [http://linux.die.net/man/1/quilt quilt] tool to manage series of patches.

'''Mini-Howto:'''

Assuming kernel sources are in directory /usr/src/linux.

1. cd /usr/src/linux

2. mkdir patches

3. Copy all patches you want to apply to ''patches'' subdirectory

4. Create ''series'' file in ''patches'' subdirectory and write names of patch files each on separate line. The order
the patches are stated in the file is significant!! The patch on the first line will be applied first followed by others.

4. ''quilt push'' (''quilt pop'') - applies (unapplies) all patches in ''series'' file

==Building kernel==

'''2.4 kernel sources''' for MPC5200 can be found in ''eCos_Linux_boa5200/tgz'' directory on BOARD DOCUMENTATION CD or from ftp://rtime.felk.cvut.cz/MPC5200/kernel_2.4/linuxppc-2.4-boa5200-release_2006_05_10.tgz.

'''2.6 Kernel sources''' for MPC5200 can be downloaded from ftp://rtime.felk.cvut.cz/MPC5200/linuxppc-2.6.18-1_AM.tar.gz.
Default kernel configuration file is ftp://rtime.felk.cvut.cz/MPC5200/config-2.6.18-1_AM.
Do not forget to set ARCH and CROSS_COMPILE variables to this values in Makefile:
ARCH=ppc
CROSS_COMPILE=powerpc-603e-linux-gnu-

After compilation a built image is placed into arch/ppc/boot/image directory.

The following commnad will install modules into ''<directory>''/lib/modules/...
make INSTALL_MOD_PATH=''<directory>'' modules_install

'''Recommendation:'''

1. Make the building directory linuxppc-2.6.18-1_AM_build, where object files will be placed, outside the origin source directory linuxppc-2.6.18-1_AM

mkdir linuxppc-2.6.18-1_AM_build

2.
cd linuxppc-2.6.18-1_AM
linuxppc-2.6.18-1_AM directory must be clean i.e. no make, make menuconfig executed from this directory
before!

3.
make O=../linuxppc-2.6.18-1_AM_build menuconfig
kernel config file (.config) will be created in linuxppc-2.6.18-1_AM_build

Next time, always run make menuconfig always from the building directory, i.e. linuxppc-2.6.18-1_AM_build

4.
cd linuxppc-2.6.18-1_AM_build

5.
Download ftp://rtime.felk.cvut.cz/MPC5200/GNUmakefile

6.
Edit GNUmakefile and change paths in KERNELSRC and KERNELOUTPUT variables

7.
make && make modules_install

== Loading kernel ==

You can test your new image on the board as follows:
# load kernel image from tftp server into memory
RedBoot> load zImage.elf

# execute image; root directory (/) is on flash memory
RedBoot> exec
If you want to load the kernel from different TFTP server than the one provided by DHCP, you can use the following command to set the IP address of your server:
RedBoot> ip_address -h 147.32.86.<xxx>

'''CAUTION:''' you must boot the kernel by RedBoot release at least 2007_02_01 otherwise it will not run! So you must load into RAM and then run the appropriate RedBoot image (or replace/update its image on flash with the new one - see
the next section) and after then you can execute kernel image.

==Updating RedBoot==
Download ftp://rtime.felk.cvut.cz/MPC5200/MPC5200-2007.02.01-redbootROMRAM.srec

'''!!! Warning: File names are case-sensitive !!!'''

# load RedBoot image from tftp server into memory at the address 0x100000
RedBoot>lo -b 0x100000 MPC5200-2007.02.01-redbootROMRAM.srec

'''!!! Warning: File names are case-sensitive !!!'''

# write image in flash memory
RedBoot>fi cr RedBoot
RedBoot>reset

If upgrade fails you can fallback to ROM Redboot image by typing 'A&M:'

If image of ROMRAM version of RedBoot with name "RedBoot" (case sensitive!!) is not found in FLASH minimal version of ROM RedBoot is started. This version does not support many services like TFTP protocol and FLASH management. To download ROMRAM version of RedBoot to FLASH it is necessary to follow these steps:

Load RAM version of RedBoot to BOA using xmodem (the image file MPC5200-2006.05.10-redbootRAM.srec is placed on BOA original CD):
RedBoot> lo -m xmodem

When finished RedBoot should answer with something like that:

CEntry point: 0x00080100, address range: 0x00080000-0x000bea04
xyzModem - CRC mode, 5763(SOH)/0(STX)/0(CAN) packets, 1 retries

Then start the RedBoot:
RedBoot> go

RAM RedBoot should start now. Download the new version of ROMRAM RedBoot to FLASH according to the steps above.

==NFS-root setup==

During the development phase of application it must be tested many times. However, it is annoying to copy several application files to flash memory every time. The practical solution is to mount via NFS working directory or whole root directory from the point of OS running on the board.

You can download already prepared root directory from ftp://rtime.felk.cvut.cz/MPC5200/MPC5200_root_070321.tar.gz

To export /var/MPC5200_root directory via NFS add the following line to /etc/exports:

/var/MPC5200_root 192.168.10.0/255.255.255.0(rw,sync,no_root_squash)

Then run command 'exportfs -ra' so that the change take an effect.

If you want MPC5200 to be mount as root directory instead of that one in flash memory:
# load kernel image from tftp server into memory
RedBoot> load zImage.elf
# execute kernel image with information where to
# find root directory in parameter string
RedBoot> ex -c "root=/dev/nfs rw nfsroot=192.168.10.1:/var/MPC5200_root ip=dhcp"

NOTE: exportfs is a part of knfs package for debian systems (ubuntu,...)

== Login with telnet ==
telnet <ip address of boa>
Log in as root, ask me for the password. --[[User:Sojka|Sojka]] 20:42, 21 March 2007 (CET)
==Setting up BOA5200==

Use 'fconfig' command (see http://ecos.sourceware.org/ecos/docs-latest/redboot/persistent-state-flash.html manual) to set up BOA5200 configuration. Recommended configuration:

Run script at boot: true
Boot script:
load zImage.elf
ex -c "root=/dev/nfs rw nfsroot=192.168.123.254:/var/MPC5200_root ip=dhcp"
Boot script timeout (1000ms resolution): 10
Use BOOTP for network configuration: true
Default server IP address: IP address of your computer
FEC Network hardware address [MAC]: choose MAC address of the unit (example: 0x00:0x00:0x00:0x00:0x00:0x02)
GDB connection port: 9000
Force console for special debug messages: false
Network debug at boot time: false
Update RedBoot non-volatile configuration - continue (y/n)? y

==Socketcan==

Prior to compiling linux kernel with socketcan driver, it is necessary to [http://rtime.felk.cvut.cz/hw/index.php/HOWTO#Applying_kernel_patches apply kernel patches] , which can be found in [http://rtime.felk.cvut.cz/repos/boa5200-linux/patches/ DARCS repository]

To set up can interface, it is necessary to configure the communication speed first and then bring the interface up. Communication speed can be set up using following command (for can0 interface):

echo 660000 >/sys/class/net/can0/can_baudrate

The constant 660000 was found experimentally, driver seems to calculate the transmission speed improperly. To bring up the can network interface, use the same command as with any other network interface, i.e.

ifconfig can0 up

The most comfortable way of setting up both can interfaces upon startup of system is to place following script to /etc/init.d/ (name it 'can', for example)

echo 660000 >/sys/class/net/can0/can_baudrate
echo 660000 >/sys/class/net/can1/can_baudrate
ifconfig can0 up
ifconfig can1 up

==CanFestival==

===Obtaining and building CanFestival===

CanFestival driver source can be downloaded from. The primary way how to do it is to check out the source directory from CanFestival CVS by these steps:
cvs -d:pserver:anonymous@lolitech.dyndns.org:/canfestival login
(type return, without entering a password)
The system will respond:
Logging in to :pserver:anonymous@lolitech.dyndns.org:2401/canfestival
Then, enter:
cvs -z3 -d:pserver:anonymous@lolitech.dyndns.org:/canfestival co -P CanFestival-3
Then insert CanFestival folder and run this commands:
./configure --timers=unix --can=socket --cc=powerpc-603e-linux-gnu-gcc --arch=ppc --os=linux --target=unix
make
make install
Building of CanFestival will produce some libraries and copy them to /usr/powerpc-603e-linux-gnu/lib folder.

===Setting up local CANopen node===

CanFestival source includes tool called ''objdictedit''. This program has graphical user interface and serves to creating configuration of the CANopen node of application we develop. It is started by command ''objdictedit''. Using this program you can create the object dictionary for the CanFestival. Mainly it is necessary to set up all SDO and PDO, the node has to send and receive. To each PDO you have to define more things - PDO receive or transmit, variable to be mapped and variable mapping. The variable will then be used in application code to exchange data between CanFestival driver and application. If you set up PDOs here they will be sent and received automatically and the values will be stored into mapped variable. Setting up SDO means that you can use it in your application, but if you want to send it, it has to be done in code.
After creating this basic configuration you have to build the dictionary which results into to files with extensions .h and .c. You have to link these files with your application.

===Initializing and starting CanFestival===

To explain how to use CanFestival I include some code examples. It supposes node configuration generated by ''objdictedit'' which name is ''canopen''. It is then used as prefix of automatically generated functions and variables (''canopen_Data'' is for example object dictionary used by CanFestival).
Header ''canfestival.h'' has to be included. For start using CanFestival it is necessary to load dynamic library with CAN bus driver API created while compiling CanFestival source. In the example SocketCan driver is used to access CAN bus.
if(!LoadCanDriver("libcanfestival_can_socket.so")) {
exit -1;
}
Then you have to open CAN device. Parameters of the communication have to be prepared in structure of type ''s_Board''. In this case CAN is set to use device ''can1'' and baudrate 1Mbps. Handler of the bus is then stored to variable of type ''CAN_HANDLE''.
/**
* CAN board definition.
* Device name can1, baudrate 1M
*/
s_BOARD canopen_board = {"1", "1000"};

CAN_HANDLE canopen_handle;

if(!(canopen_handle = canOpen(&canopen_board, &canopen_Data))) {
exit -1;
}
CanFestival implements callbacks to some events like change of state or message reception. There are pointers to callback functions in ''canopen_Data'' structure. You can assign your own functions to these pointers or leave them unused.
canopen_Data.initialisation = canopen_initialisation;
canopen_Data.preOperational = canopen_preOperational;
canopen_Data.operational = canopen_operational;
canopen_Data.post_sync = canopen_post_sync;
canopen_Data.post_TPDO = canopen_post_TPDO;
canopen_Data.stopped = canopen_stopped;
After setting up these few things you have to call function ''StartTimerLoop'' which initializes CanFestival timers. As an argument you have to insert pointer to the first function you want to proceed after starting the timers.
StartTimerLoop(&initNode);
Here is an example of such a function. It sets local node ID to 1 and bring the node to operation state. Callback functions are called after changing state if used.
void initNode(CO_Data * d, UNS32 id)
{
setNodeId(&canopen_Data, 0x01);
setState(&canopen_Data, Initialisation);
setState(&canopen_Data, Operational);
}

===Stopping CanFestival===

After finishing work with CANopen it is good to stop the communication and timers and close the device. It is done by these few functions.
setState(&canopen_Data, Stopped);
StopTimerLoop();
canClose(&canopen_Data);
canopen_handle = NULL;

===Writing to Object dictionary===

CANopen devices and all network services of each node are configured by writing to device object dictionary (OD). It is different while writing to local OD or OD of some network device.
====Writing to local OD====
Function ''WriteLocalDict'' is used for writing to OD of local node managed by CanFestival.
UNS32 writeLocalDict( CO_Data* d,
UNS16 wIndex,
UNS8 bSubindex,
void * pSourceData,
UNS8 * pExpectedSize,
UNS8 checkAccess);
Meaning of function arguments:
'''d''' - pointer to local object dictionary structure
'''wIndex''' - the index in the object dictionary where you want to write an entry
'''bSubindex''' - the subindex of the Index. e.g. mostly subindex 0 is used to tell you how many valid entries you can find in this index. Look at the canopen standard for further information
'''pbSourceData''' - pointer to the variable that holds the value that should be copied into the object dictionary
'''pExpectedSize''' - pointer to variable with size of the data to be written
'''CheckAccess''' - if other than 0, do not read if the data is Read Only or Constant

====Writing to network OD====

It is necessary to use SDO service for writing data to OD of some network device. Each CANopen device has at least one SDO server. It means that it is able to receive SDOs with one ID and answer by SDOs with another ID. It is usual that the server listen for SDOs with ID 0x600 + ID of the node and transmits SDOs of ID 0x580 + node ID. Each SDO we want to use has to be defined while creating node configuration by ''objdictedit''. Then the SDO is sent by calling appropriate function. The best is to use function ''writeNetworkDictCallBack'' which syntax is shown below.
UNS8 writeNetworkDictCallBack (CO_Data* d,
UNS8 nodeId,
UNS16 index,
UNS8 subIndex,
UNS8 count,
UNS8 dataType,
void *data,
SDOCallback_t Callback);
Meaning of function arguments:
'''d''' - pointer to local object dictionary structure
'''nodeId''' - ID of the device we want to send SDO
'''index''' - the index in the object dictionary where you want to write an entry
'''subIndex''' - the subindex of the Index. e.g. mostly subindex 0 is used to tell you how many valid entries you can find in this index. Look at the canopen standard for further information
'''count''' - number of bytes to be written
'''dataType''' - type of the data, use 0 for integers, real numbers and other values
'''data''' - pointer to the data
'''Callback''' - pointer to a function which is called after finishing the transfer
The SDO service is by definition confirmed. It means that SDO server sends response with result of the transfer after each SDO reception. This response has to be read by client to be sure that the data were written correctly. The result should be read in your function which pointer is given to the function ''writeNetworkDictCallBack'' as parameter ''callback''. The result of SDO transfer in such a function is read by CanFestival function ''getWriteResultNetworkDict''. This function has to be called after each SDO transmission because it releases line used to transfer. Header of this function is:
UNS8 getWriteResultNetworkDict (CO_Data* d, UNS8 nodeId, UNS32 * abortCode);
And meaning of function arguments is:
'''d''' - pointer to local object dictionary structure
'''nodeId''' - ID of the device we have sent SDO
'''abortCode''' - pointer to the variable where error code is written in case of error
The function can return one of these values according to the SDO transfer state:
'''SDO_FINISHED''' - data is available
'''SDO_ABORTED_RCV''' - Transfer failed. (abort SDO received)
'''SDO_ABORTED_INTERNAL''' - Transfer failed. Internal abort.
'''SDO_DOWNLOAD_IN_PROGRESS''' - Data not yet available
The function can be used in cycle waiting while return value is ''SDO_DOWNLOAD_IN_PROGRESS''. But the better solution is calling it in callback function from ''writeNetworkDictCallBack''. The callback is call after finishing the transfer.

===Using PDO service===

Using PDO service for data exchange is very easy in CanFestival. The most usual transmission type of PDOs is that they are transmitted after SYNC message. In this case it just has to be set up in objdictedit configuration and then it works, reads and stores values into mapped variables. After each PDO reception or transmission ''post_TPDO'' callback is called if used.
Sometimes it is necessary to send PDO from code without SYNC message reception. This is done by calling the function ''sendPDOevent'' with this syntax:
UNS8 sendPDOevent(CO_Data* d);
where ''d'' is the pointer to local object dictionary structure. This function sends all PDOs defined by ''objdictedit'' and transmission type ''after event'' (0x255).

===Generating SYNC message===

If you want to set up local node to become the SYNC server you have to write some information to local OD. Here is an example of function which set up the SYNC messages generation:
/**
* This function initializes local canopen node to send SYNC message
* with given period.
* @param d - local object dictionary
* @param period - period of the SYNC message in us
*/
void synchro_setup(CO_Data *d, unsigned long period)
{
UNS32 SYNC_COBID = 0x40000080;
UNS32 SYNC_INTER = period;
UNS8 size = sizeof(UNS32);
writeLocalDict(d, 0x1006, 0x0, &SYNC_INTER, &size, RW);
writeLocalDict(d, 0x1005, 0x0, &SYNC_COBID, &size, RW);
}
According to CANopen specification ID of the SYNC message is 0x80.
After the setup it can be started by command ''startSYNC(CO_Data *d)'' and stopped by command ''stopSYNC(CO_Data *d)''.

===SDO and PDO example===

At the end I attach example of a function (''cpd_start()'') which starts some device communicating by CANopen. The ID of the device is given by the parameter. The other function (''cpd_checkSDO_start()'') is callback used to handle SDO transfer result. It is necessary to wait until one SDO transfer is finished before starting some other. Global variable ''cpd_init_step'' is used for counting actual step of SDO transfer. If some SDO transfer fails it is set to -1 and the startup process is terminated.
/**
* This function is given to the writeNetworkDict function as a callback.
* It checks the result of SDO transmition and after finishing the transmition
* it closes the transfer.
* @param d - local object disctionary
* @param nodeID - ID of the node which the local node is communicating with
*/
void cpd_checkSDO_start(CO_Data* d, UNS8 nodeId)
{
UNS32 abortCode;
if(getWriteResultNetworkDict (d, nodeId, &abortCode) != SDO_FINISHED) {
cpd_init_step = -1;
}
closeSDOtransfer(&canopen_Data, nodeId, SDO_CLIENT);
cpd_start(&canopen_Data, nodeId);
}

/**
* This function switch canopen device into operational state.
* @param d - local object dictionary
* @param nodeId - ID of the device
* return 0 - ok, -1 - failed
*/
int cpd_start(CO_Data *d, UNS8 nodeId)
{
UNS8 data8;
UNS16 data16;
UNS32 data32;
switch(cpd_init_step++) {
case 0:
masterSendNMTstateChange(d, nodeId, NMT_Start_Node);
cpd_controlword = 0;
sendPDOevent(d);
cpd_controlword = 6;
sendPDOevent(d);
cpd_controlword = 0x0F;
sendPDOevent(d);

// Start operational mode
data8 = 0xFC;
writeNetworkDictCallBack(d, nodeId, 0x6060, 0x00, 1, 0, &data8, cpd_checkSDO_start);
break;
case 1:
// Check operation status
readNetworkDictCallback(d, nodeId, 0x6061, 0x00, 0, cpd_checkSDO_start);
break;
case 2:
// Setpoint specification
data16 = 0x0002;
writeNetworkDictCallBack(d, nodeId, 0x301B, 0x11, 2, 0, &data16, cpd_checkSDO_start);
break;
case 3:
canopen_init_result = 0;
cpd_init_step = 0;
break;
case -1:
canopen_init_result = -1;
cpd_init_step = 0;
break;
}
return 0;
}

===Emergency message===

New version of CanFestival is extended by EMCY messages support. There is callback added which can be set to point to your own EMCY message handler.This handler has to be a function with three parameters defined in this way:
void my_post_emcy(UNS8 nodeID, UNS16 errCode, UNS8 errReg)
After reception of an EMCY message this callback is called. The parameters keep information about node ID of the EMCY producer, error code and content of the error register.
To register your handler you have to set the callback in CanFestival initialization.
my_Data.post_emcy = my_post_emcy;

Boa5200 HOWTO

2007-11-04T15:50:20Z

Hamacl1: /* Using PDO service */

==Introduction==
This document describes how to install and setup Linux and development environment for BOA5200 board.
Assume that you have a development machine (your PC) that you use for development and building your applications which you consequently want to get running and test on BOA5200.

==Serial line setting==
The easiest way to communicate with the board ,when there is no OS and remote shell running on it, is over serial line. Recommended serial communication program is minicom. Setup minicom as follows:

Baud Rate – 38400

Bits - 8

Parity – N

Stop Bits - 1

Hardware Flow Control:- No

Software Flow Control:- No

After the setup you will see Redboot> command prompt. Here you can enter Redboot`s commands.
Redboot is a simple boot manager bulit upon eCos real-time OS. For more details , see http://ecos.sourceware.org/ecos/docs-latest/redboot/redboot-guide.html.

==DHCP server setup==
Redboot supports BOOTP protocol which means that it is able to get network information(IP,netmask,gateway IP address,etc.) from DHCP server(provides BOOTP besides DHCP protocol). Install dhcp server (on debian: apt-get install dhcpd) on your development machine. Example of my dhcp configuration file /etc/dhcpd.conf:
# I have two ethernet interfaces:
# eth0 - Internet
# eth1 - connection to BOA5200 (IP= 192.168.10.1)
# I do not want to progate infos to 147.32.0.0 subnetwork
subnet 147.32.0.0 netmask 255.255.0.0 {
}

# private subnetwork
subnet 192.168.10.0 netmask 255.255.255.0 {
option broadcast-address 192.168.10.255;
option routers 192.168.10.1;
option subnet-mask 255.255.255.0;
default-lease-time 600;
max-lease-time 7200;

# settings for BOA5200
host BOA5200 {
hardware ethernet 00:08:f1:11:22:33;
fixed-address 192.168.10.2;
}
}

Start dhcp server and reboot the board. After booting it has assigned IP, netmask and gateway address:
+PHY0: AMD AM79C874
FEC eth0: 100Mb/Full Duplex
Ethernet eth0: MAC address 00:08:f1:11:22:33
IP: 192.168.10.2/255.255.255.0, Gateway: 192.168.10.1
Default server: 192.168.10.1

==TFTP server setup==
Redboot is able to load file from remote tftp server into memory. Tftp server is lanuched by inetd daemon when a new
connection comes.
Therefore add the following line into /etc/inetd.conf :
tftp dgram udp wait nobody /usr/sbin/tcpd /usr/sbin/in.tftpd

Default tftp root directory is /tftpboot. You can change it by calling in.tftpd with specified directory as a parameter.

===Alternative way for Ubuntu based distro===

1. Install tftpd and related packages.
sudo apt-get install xinetd tftpd tftp

2. Create /etc/xinetd.d/tftp and put this entry:

service tftp
{
protocol = udp
port = 69
socket_type = dgram
wait = yes
user = nobody
server = /usr/sbin/in.tftpd
server_args = /tftpboot
disable = no
}

3. Make /tftpboot directory

sudo mkdir /tftpboot
sudo chmod -R 777 /tftpboot
sudo chown -R nobody /tftpboot

4. Start tftpd through xinetd

sudo /etc/init.d/xinetd start

see [[http://www.example.com Installing and setting TFTPD in Ubuntu]]

==Tool chain==
Toolchain(gcc, ld, ...) for MPC5200 can be downloaded from ftp://rtime.felk.cvut.cz/MPC5200/gcc-powerpc-603e-linux-gnu-4.1.1-bin.tar.gz
Unpack the archive:

cd /
tar xvzf gcc-powerpc-603e-linux-gnu-4.1.1-bin.tar.gz

You can also create a debian package from archive and then install the package:
alien --to-deb gcc-powerpc-603e-linux-gnu-4.1.1-bin.tar.gz
Note: If you are not root, use fakeroot to run the command.

==Applying kernel patches==
It is recommended to use [http://linux.die.net/man/1/quilt quilt] tool to manage series of patches.

'''Mini-Howto:'''

Assuming kernel sources are in directory /usr/src/linux.

1. cd /usr/src/linux

2. mkdir patches

3. Copy all patches you want to apply to ''patches'' subdirectory

4. Create ''series'' file in ''patches'' subdirectory and write names of patch files each on separate line. The order
the patches are stated in the file is significant!! The patch on the first line will be applied first followed by others.

4. ''quilt push'' (''quilt pop'') - applies (unapplies) all patches in ''series'' file

==Building kernel==

'''2.4 kernel sources''' for MPC5200 can be found in ''eCos_Linux_boa5200/tgz'' directory on BOARD DOCUMENTATION CD or from ftp://rtime.felk.cvut.cz/MPC5200/kernel_2.4/linuxppc-2.4-boa5200-release_2006_05_10.tgz.

'''2.6 Kernel sources''' for MPC5200 can be downloaded from ftp://rtime.felk.cvut.cz/MPC5200/linuxppc-2.6.18-1_AM.tar.gz.
Default kernel configuration file is ftp://rtime.felk.cvut.cz/MPC5200/config-2.6.18-1_AM.
Do not forget to set ARCH and CROSS_COMPILE variables to this values in Makefile:
ARCH=ppc
CROSS_COMPILE=powerpc-603e-linux-gnu-

After compilation a built image is placed into arch/ppc/boot/image directory.

The following commnad will install modules into ''<directory>''/lib/modules/...
make INSTALL_MOD_PATH=''<directory>'' modules_install

'''Recommendation:'''

1. Make the building directory linuxppc-2.6.18-1_AM_build, where object files will be placed, outside the origin source directory linuxppc-2.6.18-1_AM

mkdir linuxppc-2.6.18-1_AM_build

2.
cd linuxppc-2.6.18-1_AM
linuxppc-2.6.18-1_AM directory must be clean i.e. no make, make menuconfig executed from this directory
before!

3.
make O=../linuxppc-2.6.18-1_AM_build menuconfig
kernel config file (.config) will be created in linuxppc-2.6.18-1_AM_build

Next time, always run make menuconfig always from the building directory, i.e. linuxppc-2.6.18-1_AM_build

4.
cd linuxppc-2.6.18-1_AM_build

5.
Download ftp://rtime.felk.cvut.cz/MPC5200/GNUmakefile

6.
Edit GNUmakefile and change paths in KERNELSRC and KERNELOUTPUT variables

7.
make && make modules_install

== Loading kernel ==

You can test your new image on the board as follows:
# load kernel image from tftp server into memory
RedBoot> load zImage.elf

# execute image; root directory (/) is on flash memory
RedBoot> exec
If you want to load the kernel from different TFTP server than the one provided by DHCP, you can use the following command to set the IP address of your server:
RedBoot> ip_address -h 147.32.86.<xxx>

'''CAUTION:''' you must boot the kernel by RedBoot release at least 2007_02_01 otherwise it will not run! So you must load into RAM and then run the appropriate RedBoot image (or replace/update its image on flash with the new one - see
the next section) and after then you can execute kernel image.

==Updating RedBoot==
Download ftp://rtime.felk.cvut.cz/MPC5200/MPC5200-2007.02.01-redbootROMRAM.srec

'''!!! Warning: File names are case-sensitive !!!'''

# load RedBoot image from tftp server into memory at the address 0x100000
RedBoot>lo -b 0x100000 MPC5200-2007.02.01-redbootROMRAM.srec

'''!!! Warning: File names are case-sensitive !!!'''

# write image in flash memory
RedBoot>fi cr RedBoot
RedBoot>reset

If upgrade fails you can fallback to ROM Redboot image by typing 'A&M:'

If image of ROMRAM version of RedBoot with name "RedBoot" (case sensitive!!) is not found in FLASH minimal version of ROM RedBoot is started. This version does not support many services like TFTP protocol and FLASH management. To download ROMRAM version of RedBoot to FLASH it is necessary to follow these steps:

Load RAM version of RedBoot to BOA using xmodem (the image file MPC5200-2006.05.10-redbootRAM.srec is placed on BOA original CD):
RedBoot> lo -m xmodem

When finished RedBoot should answer with something like that:

CEntry point: 0x00080100, address range: 0x00080000-0x000bea04
xyzModem - CRC mode, 5763(SOH)/0(STX)/0(CAN) packets, 1 retries

Then start the RedBoot:
RedBoot> go

RAM RedBoot should start now. Download the new version of ROMRAM RedBoot to FLASH according to the steps above.

==NFS-root setup==

During the development phase of application it must be tested many times. However, it is annoying to copy several application files to flash memory every time. The practical solution is to mount via NFS working directory or whole root directory from the point of OS running on the board.

You can download already prepared root directory from ftp://rtime.felk.cvut.cz/MPC5200/MPC5200_root_070321.tar.gz

To export /var/MPC5200_root directory via NFS add the following line to /etc/exports:

/var/MPC5200_root 192.168.10.0/255.255.255.0(rw,sync,no_root_squash)

Then run command 'exportfs -ra' so that the change take an effect.

If you want MPC5200 to be mount as root directory instead of that one in flash memory:
# load kernel image from tftp server into memory
RedBoot> load zImage.elf
# execute kernel image with information where to
# find root directory in parameter string
RedBoot> ex -c "root=/dev/nfs rw nfsroot=192.168.10.1:/var/MPC5200_root ip=dhcp"

NOTE: exportfs is a part of knfs package for debian systems (ubuntu,...)

== Login with telnet ==
telnet <ip address of boa>
Log in as root, ask me for the password. --[[User:Sojka|Sojka]] 20:42, 21 March 2007 (CET)
==Setting up BOA5200==

Use 'fconfig' command (see http://ecos.sourceware.org/ecos/docs-latest/redboot/persistent-state-flash.html manual) to set up BOA5200 configuration. Recommended configuration:

Run script at boot: true
Boot script:
load zImage.elf
ex -c "root=/dev/nfs rw nfsroot=192.168.123.254:/var/MPC5200_root ip=dhcp"
Boot script timeout (1000ms resolution): 10
Use BOOTP for network configuration: true
Default server IP address: IP address of your computer
FEC Network hardware address [MAC]: choose MAC address of the unit (example: 0x00:0x00:0x00:0x00:0x00:0x02)
GDB connection port: 9000
Force console for special debug messages: false
Network debug at boot time: false
Update RedBoot non-volatile configuration - continue (y/n)? y

==Socketcan==

Prior to compiling linux kernel with socketcan driver, it is necessary to [http://rtime.felk.cvut.cz/hw/index.php/HOWTO#Applying_kernel_patches apply kernel patches] , which can be found in [http://rtime.felk.cvut.cz/repos/boa5200-linux/patches/ DARCS repository]

To set up can interface, it is necessary to configure the communication speed first and then bring the interface up. Communication speed can be set up using following command (for can0 interface):

echo 660000 >/sys/class/net/can0/can_baudrate

The constant 660000 was found experimentally, driver seems to calculate the transmission speed improperly. To bring up the can network interface, use the same command as with any other network interface, i.e.

ifconfig can0 up

The most comfortable way of setting up both can interfaces upon startup of system is to place following script to /etc/init.d/ (name it 'can', for example)

echo 660000 >/sys/class/net/can0/can_baudrate
echo 660000 >/sys/class/net/can1/can_baudrate
ifconfig can0 up
ifconfig can1 up

==CanFestival==

===Obtaining and building CanFestival===

CanFestival driver source can be downloaded from. The primary way how to do it is to check out the source directory from CanFestival CVS by these steps:
cvs -d:pserver:anonymous@lolitech.dyndns.org:/canfestival login
(type return, without entering a password)
The system will respond:
Logging in to :pserver:anonymous@lolitech.dyndns.org:2401/canfestival
Then, enter:
cvs -z3 -d:pserver:anonymous@lolitech.dyndns.org:/canfestival co -P CanFestival-3
Then insert CanFestival folder and run this commands:
./configure --timers=unix --can=socket --cc=powerpc-603e-linux-gnu-gcc --arch=ppc --os=linux --target=unix
make
make install
Building of CanFestival will produce some libraries and copy them to /usr/powerpc-603e-linux-gnu/lib folder.

===Setting up local CANopen node===

CanFestival source includes tool called ''objdictedit''. This program has graphical user interface and serves to creating configuration of the CANopen node of application we develop. It is started by command ''objdictedit''. Using this program you can create the object dictionary for the CanFestival. Mainly it is necessary to set up all SDO and PDO, the node has to send and receive. To each PDO you have to define more things - PDO receive or transmit, variable to be mapped and variable mapping. The variable will then be used in application code to exchange data between CanFestival driver and application. If you set up PDOs here they will be sent and received automatically and the values will be stored into mapped variable. Setting up SDO means that you can use it in your application, but if you want to send it, it has to be done in code.
After creating this basic configuration you have to build the dictionary which results into to files with extensions .h and .c. You have to link these files with your application.

===Initializing and starting CanFestival===

To explain how to use CanFestival I include some code examples. It supposes node configuration generated by ''objdictedit'' which name is ''canopen''. It is then used as prefix of automatically generated functions and variables (''canopen_Data'' is for example object dictionary used by CanFestival).
Header ''canfestival.h'' has to be included. For start using CanFestival it is necessary to load dynamic library with CAN bus driver API created while compiling CanFestival source. In the example SocketCan driver is used to access CAN bus.
if(!LoadCanDriver("libcanfestival_can_socket.so")) {
exit -1;
}
Then you have to open CAN device. Parameters of the communication have to be prepared in structure of type ''s_Board''. In this case CAN is set to use device ''can1'' and baudrate 1Mbps. Handler of the bus is then stored to variable of type ''CAN_HANDLE''.
/**
* CAN board definition.
* Device name can1, baudrate 1M
*/
s_BOARD canopen_board = {"1", "1000"};

CAN_HANDLE canopen_handle;

if(!(canopen_handle = canOpen(&canopen_board, &canopen_Data))) {
exit -1;
}
CanFestival implements callbacks to some events like change of state or message reception. There are pointers to callback functions in ''canopen_Data'' structure. You can assign your own functions to these pointers or leave them unused.
canopen_Data.initialisation = canopen_initialisation;
canopen_Data.preOperational = canopen_preOperational;
canopen_Data.operational = canopen_operational;
canopen_Data.post_sync = canopen_post_sync;
canopen_Data.post_TPDO = canopen_post_TPDO;
canopen_Data.stopped = canopen_stopped;
After setting up these few things you have to call function ''StartTimerLoop'' which initializes CanFestival timers. As an argument you have to insert pointer to the first function you want to proceed after starting the timers.
StartTimerLoop(&initNode);
Here is an example of such a function. It sets local node ID to 1 and bring the node to operation state. Callback functions are called after changing state if used.
void initNode(CO_Data * d, UNS32 id)
{
setNodeId(&canopen_Data, 0x01);
setState(&canopen_Data, Initialisation);
setState(&canopen_Data, Operational);
}

===Stopping CanFestival===

After finishing work with CANopen it is good to stop the communication and timers and close the device. It is done by these few functions.
setState(&canopen_Data, Stopped);
StopTimerLoop();
canClose(&canopen_Data);
canopen_handle = NULL;

===Writing to Object dictionary===

CANopen devices and all network services of each node are configured by writing to device object dictionary (OD). It is different while writing to local OD or OD of some network device.
====Writing to local OD====
Function ''WriteLocalDict'' is used for writing to OD of local node managed by CanFestival.
UNS32 writeLocalDict( CO_Data* d,
UNS16 wIndex,
UNS8 bSubindex,
void * pSourceData,
UNS8 * pExpectedSize,
UNS8 checkAccess);
Meaning of function arguments:
'''d''' - pointer to local object dictionary structure
'''wIndex''' - the index in the object dictionary where you want to write an entry
'''bSubindex''' - the subindex of the Index. e.g. mostly subindex 0 is used to tell you how many valid entries you can find in this index. Look at the canopen standard for further information
'''pbSourceData''' - pointer to the variable that holds the value that should be copied into the object dictionary
'''pExpectedSize''' - pointer to variable with size of the data to be written
'''CheckAccess''' - if other than 0, do not read if the data is Read Only or Constant

====Writing to network OD====

It is necessary to use SDO service for writing data to OD of some network device. Each CANopen device has at least one SDO server. It means that it is able to receive SDOs with one ID and answer by SDOs with another ID. It is usual that the server listen for SDOs with ID 0x600 + ID of the node and transmits SDOs of ID 0x580 + node ID. Each SDO we want to use has to be defined while creating node configuration by ''objdictedit''. Then the SDO is sent by calling appropriate function. The best is to use function ''writeNetworkDictCallBack'' which syntax is shown below.
UNS8 writeNetworkDictCallBack (CO_Data* d,
UNS8 nodeId,
UNS16 index,
UNS8 subIndex,
UNS8 count,
UNS8 dataType,
void *data,
SDOCallback_t Callback);
Meaning of function arguments:
'''d''' - pointer to local object dictionary structure
'''nodeId''' - ID of the device we want to send SDO
'''index''' - the index in the object dictionary where you want to write an entry
'''subIndex''' - the subindex of the Index. e.g. mostly subindex 0 is used to tell you how many valid entries you can find in this index. Look at the canopen standard for further information
'''count''' - number of bytes to be written
'''dataType''' - type of the data, use 0 for integers, real numbers and other values
'''data''' - pointer to the data
'''Callback''' - pointer to a function which is called after finishing the transfer
The SDO service is by definition confirmed. It means that SDO server sends response with result of the transfer after each SDO reception. This response has to be read by client to be sure that the data were written correctly. The result should be read in your function which pointer is given to the function ''writeNetworkDictCallBack'' as parameter ''callback''. The result of SDO transfer in such a function is read by CanFestival function ''getWriteResultNetworkDict''. This function has to be called after each SDO transmission because it releases line used to transfer. Header of this function is:
UNS8 getWriteResultNetworkDict (CO_Data* d, UNS8 nodeId, UNS32 * abortCode);
And meaning of function arguments is:
'''d''' - pointer to local object dictionary structure
'''nodeId''' - ID of the device we have sent SDO
'''abortCode''' - pointer to the variable where error code is written in case of error
The function can return one of these values according to the SDO transfer state:
'''SDO_FINISHED''' - data is available
'''SDO_ABORTED_RCV''' - Transfer failed. (abort SDO received)
'''SDO_ABORTED_INTERNAL''' - Transfer failed. Internal abort.
'''SDO_DOWNLOAD_IN_PROGRESS''' - Data not yet available
The function can be used in cycle waiting while return value is ''SDO_DOWNLOAD_IN_PROGRESS''. But the better solution is calling it in callback function from ''writeNetworkDictCallBack''. The callback is call after finishing the transfer.

===Using PDO service===

Using PDO service for data exchange is very easy in CanFestival. The most usual transmission type of PDOs is that they are transmitted after SYNC message. In this case it just has to be set up in objdictedit configuration and then it works, reads and stores values into mapped variables. After each PDO reception or transmission ''post_TPDO'' callback is called if used.
Sometimes it is necessary to send PDO from code without SYNC message reception. This is done by calling the function ''sendPDOevent'' with this syntax:
UNS8 sendPDOevent(CO_Data* d);
where ''d'' is the pointer to local object dictionary structure. This function sends all PDOs defined by ''objdictedit'' and transmission type ''after event'' (0x255).

===Generating SYNC message===

If you want to set up local node to become the SYNC server you have to write some information to local OD. Here is an example of function which set up the SYNC messages generation:
/**
* This function initializes local canopen node to send SYNC message
* with given period.
* @param d - local object dictionary
* @param period - period of the SYNC message in us
*/
void synchro_setup(CO_Data *d, unsigned long period)
{
UNS32 SYNC_COBID = 0x40000080;
UNS32 SYNC_INTER = period;
UNS8 size = sizeof(UNS32);
writeLocalDict(d, 0x1006, 0x0, &SYNC_INTER, &size, RW);
writeLocalDict(d, 0x1005, 0x0, &SYNC_COBID, &size, RW);
}
According to CANopen specification ID of the SYNC message is 0x80.
After the setup it can be started by command ''startSYNC(CO_Data *d)'' and stopped by command ''stopSYNC(CO_Data *d)''.

===SDO and PDO example===

At the end I attach example of a function (''cpd_start()'') which starts some device communicating by CANopen. The ID of the device is given by the parameter. The other function (''cpd_checkSDO_start()'') is callback used to handle SDO transfer result. It is necessary to wait until one SDO transfer is finished before starting some other. Global variable ''cpd_init_step'' is used for counting actual step of SDO transfer. If some SDO transfer fails it is set to -1 and the startup process is terminated.
/**
* This function is given to the writeNetworkDict function as a callback.
* It checks the result of SDO transmition and after finishing the transmition
* it closes the transfer.
* @param d - local object disctionary
* @param nodeID - ID of the node which the local node is communicating with
*/
void cpd_checkSDO_start(CO_Data* d, UNS8 nodeId)
{
UNS32 abortCode;
if(getWriteResultNetworkDict (d, nodeId, &abortCode) != SDO_FINISHED) {
cpd_init_step = -1;
}
closeSDOtransfer(&canopen_Data, nodeId, SDO_CLIENT);
cpd_start(&canopen_Data, nodeId);
}

/**
* This function switch canopen device into operational state.
* @param d - local object dictionary
* @param nodeId - ID of the device
* return 0 - ok, -1 - failed
*/
int cpd_start(CO_Data *d, UNS8 nodeId)
{
UNS8 data8;
UNS16 data16;
UNS32 data32;
switch(cpd_init_step++) {
case 0:
masterSendNMTstateChange(d, nodeId, NMT_Start_Node);
s_PDO pdo;
cpd_controlword = 0;
pdo.cobId = 0x200 + nodeId;
int i = 0;
for(i = 0; i < 8; i++) {
pdo.data[i] = 0;
}
pdo.data[0] = 0;
pdo.data[1] = 0;
pdo.len = sizeof(pdo.data);
sendPDO(d, pdo, NOT_A_REQUEST);
cpd_controlword = 6;
pdo.cobId = 0x200 + nodeId;
for(i = 0; i < 8; i++) {
pdo.data[i] = 0;
}
pdo.data[0] = 7;
pdo.data[1] = 0;
pdo.len = sizeof(pdo.data);
sendPDO(d, pdo, NOT_A_REQUEST);
cpd_controlword = 0x0F;
pdo.cobId = 0x200 + nodeId;
for(i = 0; i < 8; i++) {
pdo.data[i] = 0;
}
pdo.data[0] = 0xF;
pdo.data[1] = 0;
pdo.len = sizeof(pdo.data);
sendPDO(d, pdo, NOT_A_REQUEST);

// Start operational mode
data8 = 0xFC;
writeNetworkDictCallBack(d, nodeId, 0x6060, 0x00, 1, 0, &data8, cpd_checkSDO_start);
break;
case 1:
// Check operation status
readNetworkDictCallback(d, nodeId, 0x6061, 0x00, 0, cpd_checkSDO_start);
break;
case 2:
// Setpoint specification
data16 = 0x0002;
writeNetworkDictCallBack(d, nodeId, 0x301B, 0x11, 2, 0, &data16, cpd_checkSDO_start);
break;
case 3:
canopen_init_result = 0;
cpd_init_step = 0;
break;
case -1:
canopen_init_result = -1;
cpd_init_step = 0;
break;
}
return 0;
}

===Emergency message===

New version of CanFestival is extended by EMCY messages support. There is callback added which can be set to point to your own EMCY message handler.This handler has to be a function with three parameters defined in this way:
void my_post_emcy(UNS8 nodeID, UNS16 errCode, UNS8 errReg)
After reception of an EMCY message this callback is called. The parameters keep information about node ID of the EMCY producer, error code and content of the error register.
To register your handler you have to set the callback in CanFestival initialization.
my_Data.post_emcy = my_post_emcy;

Boa5200 HOWTO

2007-11-04T15:49:25Z

Hamacl1: /* Using PDO service */

==Introduction==
This document describes how to install and setup Linux and development environment for BOA5200 board.
Assume that you have a development machine (your PC) that you use for development and building your applications which you consequently want to get running and test on BOA5200.

==Serial line setting==
The easiest way to communicate with the board ,when there is no OS and remote shell running on it, is over serial line. Recommended serial communication program is minicom. Setup minicom as follows:

Baud Rate – 38400

Bits - 8

Parity – N

Stop Bits - 1

Hardware Flow Control:- No

Software Flow Control:- No

After the setup you will see Redboot> command prompt. Here you can enter Redboot`s commands.
Redboot is a simple boot manager bulit upon eCos real-time OS. For more details , see http://ecos.sourceware.org/ecos/docs-latest/redboot/redboot-guide.html.

==DHCP server setup==
Redboot supports BOOTP protocol which means that it is able to get network information(IP,netmask,gateway IP address,etc.) from DHCP server(provides BOOTP besides DHCP protocol). Install dhcp server (on debian: apt-get install dhcpd) on your development machine. Example of my dhcp configuration file /etc/dhcpd.conf:
# I have two ethernet interfaces:
# eth0 - Internet
# eth1 - connection to BOA5200 (IP= 192.168.10.1)
# I do not want to progate infos to 147.32.0.0 subnetwork
subnet 147.32.0.0 netmask 255.255.0.0 {
}

# private subnetwork
subnet 192.168.10.0 netmask 255.255.255.0 {
option broadcast-address 192.168.10.255;
option routers 192.168.10.1;
option subnet-mask 255.255.255.0;
default-lease-time 600;
max-lease-time 7200;

# settings for BOA5200
host BOA5200 {
hardware ethernet 00:08:f1:11:22:33;
fixed-address 192.168.10.2;
}
}

Start dhcp server and reboot the board. After booting it has assigned IP, netmask and gateway address:
+PHY0: AMD AM79C874
FEC eth0: 100Mb/Full Duplex
Ethernet eth0: MAC address 00:08:f1:11:22:33
IP: 192.168.10.2/255.255.255.0, Gateway: 192.168.10.1
Default server: 192.168.10.1

==TFTP server setup==
Redboot is able to load file from remote tftp server into memory. Tftp server is lanuched by inetd daemon when a new
connection comes.
Therefore add the following line into /etc/inetd.conf :
tftp dgram udp wait nobody /usr/sbin/tcpd /usr/sbin/in.tftpd

Default tftp root directory is /tftpboot. You can change it by calling in.tftpd with specified directory as a parameter.

===Alternative way for Ubuntu based distro===

1. Install tftpd and related packages.
sudo apt-get install xinetd tftpd tftp

2. Create /etc/xinetd.d/tftp and put this entry:

service tftp
{
protocol = udp
port = 69
socket_type = dgram
wait = yes
user = nobody
server = /usr/sbin/in.tftpd
server_args = /tftpboot
disable = no
}

3. Make /tftpboot directory

sudo mkdir /tftpboot
sudo chmod -R 777 /tftpboot
sudo chown -R nobody /tftpboot

4. Start tftpd through xinetd

sudo /etc/init.d/xinetd start

see [[http://www.example.com Installing and setting TFTPD in Ubuntu]]

==Tool chain==
Toolchain(gcc, ld, ...) for MPC5200 can be downloaded from ftp://rtime.felk.cvut.cz/MPC5200/gcc-powerpc-603e-linux-gnu-4.1.1-bin.tar.gz
Unpack the archive:

cd /
tar xvzf gcc-powerpc-603e-linux-gnu-4.1.1-bin.tar.gz

You can also create a debian package from archive and then install the package:
alien --to-deb gcc-powerpc-603e-linux-gnu-4.1.1-bin.tar.gz
Note: If you are not root, use fakeroot to run the command.

==Applying kernel patches==
It is recommended to use [http://linux.die.net/man/1/quilt quilt] tool to manage series of patches.

'''Mini-Howto:'''

Assuming kernel sources are in directory /usr/src/linux.

1. cd /usr/src/linux

2. mkdir patches

3. Copy all patches you want to apply to ''patches'' subdirectory

4. Create ''series'' file in ''patches'' subdirectory and write names of patch files each on separate line. The order
the patches are stated in the file is significant!! The patch on the first line will be applied first followed by others.

4. ''quilt push'' (''quilt pop'') - applies (unapplies) all patches in ''series'' file

==Building kernel==

'''2.4 kernel sources''' for MPC5200 can be found in ''eCos_Linux_boa5200/tgz'' directory on BOARD DOCUMENTATION CD or from ftp://rtime.felk.cvut.cz/MPC5200/kernel_2.4/linuxppc-2.4-boa5200-release_2006_05_10.tgz.

'''2.6 Kernel sources''' for MPC5200 can be downloaded from ftp://rtime.felk.cvut.cz/MPC5200/linuxppc-2.6.18-1_AM.tar.gz.
Default kernel configuration file is ftp://rtime.felk.cvut.cz/MPC5200/config-2.6.18-1_AM.
Do not forget to set ARCH and CROSS_COMPILE variables to this values in Makefile:
ARCH=ppc
CROSS_COMPILE=powerpc-603e-linux-gnu-

After compilation a built image is placed into arch/ppc/boot/image directory.

The following commnad will install modules into ''<directory>''/lib/modules/...
make INSTALL_MOD_PATH=''<directory>'' modules_install

'''Recommendation:'''

1. Make the building directory linuxppc-2.6.18-1_AM_build, where object files will be placed, outside the origin source directory linuxppc-2.6.18-1_AM

mkdir linuxppc-2.6.18-1_AM_build

2.
cd linuxppc-2.6.18-1_AM
linuxppc-2.6.18-1_AM directory must be clean i.e. no make, make menuconfig executed from this directory
before!

3.
make O=../linuxppc-2.6.18-1_AM_build menuconfig
kernel config file (.config) will be created in linuxppc-2.6.18-1_AM_build

Next time, always run make menuconfig always from the building directory, i.e. linuxppc-2.6.18-1_AM_build

4.
cd linuxppc-2.6.18-1_AM_build

5.
Download ftp://rtime.felk.cvut.cz/MPC5200/GNUmakefile

6.
Edit GNUmakefile and change paths in KERNELSRC and KERNELOUTPUT variables

7.
make && make modules_install

== Loading kernel ==

You can test your new image on the board as follows:
# load kernel image from tftp server into memory
RedBoot> load zImage.elf

# execute image; root directory (/) is on flash memory
RedBoot> exec
If you want to load the kernel from different TFTP server than the one provided by DHCP, you can use the following command to set the IP address of your server:
RedBoot> ip_address -h 147.32.86.<xxx>

'''CAUTION:''' you must boot the kernel by RedBoot release at least 2007_02_01 otherwise it will not run! So you must load into RAM and then run the appropriate RedBoot image (or replace/update its image on flash with the new one - see
the next section) and after then you can execute kernel image.

==Updating RedBoot==
Download ftp://rtime.felk.cvut.cz/MPC5200/MPC5200-2007.02.01-redbootROMRAM.srec

'''!!! Warning: File names are case-sensitive !!!'''

# load RedBoot image from tftp server into memory at the address 0x100000
RedBoot>lo -b 0x100000 MPC5200-2007.02.01-redbootROMRAM.srec

'''!!! Warning: File names are case-sensitive !!!'''

# write image in flash memory
RedBoot>fi cr RedBoot
RedBoot>reset

If upgrade fails you can fallback to ROM Redboot image by typing 'A&M:'

If image of ROMRAM version of RedBoot with name "RedBoot" (case sensitive!!) is not found in FLASH minimal version of ROM RedBoot is started. This version does not support many services like TFTP protocol and FLASH management. To download ROMRAM version of RedBoot to FLASH it is necessary to follow these steps:

Load RAM version of RedBoot to BOA using xmodem (the image file MPC5200-2006.05.10-redbootRAM.srec is placed on BOA original CD):
RedBoot> lo -m xmodem

When finished RedBoot should answer with something like that:

CEntry point: 0x00080100, address range: 0x00080000-0x000bea04
xyzModem - CRC mode, 5763(SOH)/0(STX)/0(CAN) packets, 1 retries

Then start the RedBoot:
RedBoot> go

RAM RedBoot should start now. Download the new version of ROMRAM RedBoot to FLASH according to the steps above.

==NFS-root setup==

During the development phase of application it must be tested many times. However, it is annoying to copy several application files to flash memory every time. The practical solution is to mount via NFS working directory or whole root directory from the point of OS running on the board.

You can download already prepared root directory from ftp://rtime.felk.cvut.cz/MPC5200/MPC5200_root_070321.tar.gz

To export /var/MPC5200_root directory via NFS add the following line to /etc/exports:

/var/MPC5200_root 192.168.10.0/255.255.255.0(rw,sync,no_root_squash)

Then run command 'exportfs -ra' so that the change take an effect.

If you want MPC5200 to be mount as root directory instead of that one in flash memory:
# load kernel image from tftp server into memory
RedBoot> load zImage.elf
# execute kernel image with information where to
# find root directory in parameter string
RedBoot> ex -c "root=/dev/nfs rw nfsroot=192.168.10.1:/var/MPC5200_root ip=dhcp"

NOTE: exportfs is a part of knfs package for debian systems (ubuntu,...)

== Login with telnet ==
telnet <ip address of boa>
Log in as root, ask me for the password. --[[User:Sojka|Sojka]] 20:42, 21 March 2007 (CET)
==Setting up BOA5200==

Use 'fconfig' command (see http://ecos.sourceware.org/ecos/docs-latest/redboot/persistent-state-flash.html manual) to set up BOA5200 configuration. Recommended configuration:

Run script at boot: true
Boot script:
load zImage.elf
ex -c "root=/dev/nfs rw nfsroot=192.168.123.254:/var/MPC5200_root ip=dhcp"
Boot script timeout (1000ms resolution): 10
Use BOOTP for network configuration: true
Default server IP address: IP address of your computer
FEC Network hardware address [MAC]: choose MAC address of the unit (example: 0x00:0x00:0x00:0x00:0x00:0x02)
GDB connection port: 9000
Force console for special debug messages: false
Network debug at boot time: false
Update RedBoot non-volatile configuration - continue (y/n)? y

==Socketcan==

Prior to compiling linux kernel with socketcan driver, it is necessary to [http://rtime.felk.cvut.cz/hw/index.php/HOWTO#Applying_kernel_patches apply kernel patches] , which can be found in [http://rtime.felk.cvut.cz/repos/boa5200-linux/patches/ DARCS repository]

To set up can interface, it is necessary to configure the communication speed first and then bring the interface up. Communication speed can be set up using following command (for can0 interface):

echo 660000 >/sys/class/net/can0/can_baudrate

The constant 660000 was found experimentally, driver seems to calculate the transmission speed improperly. To bring up the can network interface, use the same command as with any other network interface, i.e.

ifconfig can0 up

The most comfortable way of setting up both can interfaces upon startup of system is to place following script to /etc/init.d/ (name it 'can', for example)

echo 660000 >/sys/class/net/can0/can_baudrate
echo 660000 >/sys/class/net/can1/can_baudrate
ifconfig can0 up
ifconfig can1 up

==CanFestival==

===Obtaining and building CanFestival===

CanFestival driver source can be downloaded from. The primary way how to do it is to check out the source directory from CanFestival CVS by these steps:
cvs -d:pserver:anonymous@lolitech.dyndns.org:/canfestival login
(type return, without entering a password)
The system will respond:
Logging in to :pserver:anonymous@lolitech.dyndns.org:2401/canfestival
Then, enter:
cvs -z3 -d:pserver:anonymous@lolitech.dyndns.org:/canfestival co -P CanFestival-3
Then insert CanFestival folder and run this commands:
./configure --timers=unix --can=socket --cc=powerpc-603e-linux-gnu-gcc --arch=ppc --os=linux --target=unix
make
make install
Building of CanFestival will produce some libraries and copy them to /usr/powerpc-603e-linux-gnu/lib folder.

===Setting up local CANopen node===

CanFestival source includes tool called ''objdictedit''. This program has graphical user interface and serves to creating configuration of the CANopen node of application we develop. It is started by command ''objdictedit''. Using this program you can create the object dictionary for the CanFestival. Mainly it is necessary to set up all SDO and PDO, the node has to send and receive. To each PDO you have to define more things - PDO receive or transmit, variable to be mapped and variable mapping. The variable will then be used in application code to exchange data between CanFestival driver and application. If you set up PDOs here they will be sent and received automatically and the values will be stored into mapped variable. Setting up SDO means that you can use it in your application, but if you want to send it, it has to be done in code.
After creating this basic configuration you have to build the dictionary which results into to files with extensions .h and .c. You have to link these files with your application.

===Initializing and starting CanFestival===

To explain how to use CanFestival I include some code examples. It supposes node configuration generated by ''objdictedit'' which name is ''canopen''. It is then used as prefix of automatically generated functions and variables (''canopen_Data'' is for example object dictionary used by CanFestival).
Header ''canfestival.h'' has to be included. For start using CanFestival it is necessary to load dynamic library with CAN bus driver API created while compiling CanFestival source. In the example SocketCan driver is used to access CAN bus.
if(!LoadCanDriver("libcanfestival_can_socket.so")) {
exit -1;
}
Then you have to open CAN device. Parameters of the communication have to be prepared in structure of type ''s_Board''. In this case CAN is set to use device ''can1'' and baudrate 1Mbps. Handler of the bus is then stored to variable of type ''CAN_HANDLE''.
/**
* CAN board definition.
* Device name can1, baudrate 1M
*/
s_BOARD canopen_board = {"1", "1000"};

CAN_HANDLE canopen_handle;

if(!(canopen_handle = canOpen(&canopen_board, &canopen_Data))) {
exit -1;
}
CanFestival implements callbacks to some events like change of state or message reception. There are pointers to callback functions in ''canopen_Data'' structure. You can assign your own functions to these pointers or leave them unused.
canopen_Data.initialisation = canopen_initialisation;
canopen_Data.preOperational = canopen_preOperational;
canopen_Data.operational = canopen_operational;
canopen_Data.post_sync = canopen_post_sync;
canopen_Data.post_TPDO = canopen_post_TPDO;
canopen_Data.stopped = canopen_stopped;
After setting up these few things you have to call function ''StartTimerLoop'' which initializes CanFestival timers. As an argument you have to insert pointer to the first function you want to proceed after starting the timers.
StartTimerLoop(&initNode);
Here is an example of such a function. It sets local node ID to 1 and bring the node to operation state. Callback functions are called after changing state if used.
void initNode(CO_Data * d, UNS32 id)
{
setNodeId(&canopen_Data, 0x01);
setState(&canopen_Data, Initialisation);
setState(&canopen_Data, Operational);
}

===Stopping CanFestival===

After finishing work with CANopen it is good to stop the communication and timers and close the device. It is done by these few functions.
setState(&canopen_Data, Stopped);
StopTimerLoop();
canClose(&canopen_Data);
canopen_handle = NULL;

===Writing to Object dictionary===

CANopen devices and all network services of each node are configured by writing to device object dictionary (OD). It is different while writing to local OD or OD of some network device.
====Writing to local OD====
Function ''WriteLocalDict'' is used for writing to OD of local node managed by CanFestival.
UNS32 writeLocalDict( CO_Data* d,
UNS16 wIndex,
UNS8 bSubindex,
void * pSourceData,
UNS8 * pExpectedSize,
UNS8 checkAccess);
Meaning of function arguments:
'''d''' - pointer to local object dictionary structure
'''wIndex''' - the index in the object dictionary where you want to write an entry
'''bSubindex''' - the subindex of the Index. e.g. mostly subindex 0 is used to tell you how many valid entries you can find in this index. Look at the canopen standard for further information
'''pbSourceData''' - pointer to the variable that holds the value that should be copied into the object dictionary
'''pExpectedSize''' - pointer to variable with size of the data to be written
'''CheckAccess''' - if other than 0, do not read if the data is Read Only or Constant

====Writing to network OD====

It is necessary to use SDO service for writing data to OD of some network device. Each CANopen device has at least one SDO server. It means that it is able to receive SDOs with one ID and answer by SDOs with another ID. It is usual that the server listen for SDOs with ID 0x600 + ID of the node and transmits SDOs of ID 0x580 + node ID. Each SDO we want to use has to be defined while creating node configuration by ''objdictedit''. Then the SDO is sent by calling appropriate function. The best is to use function ''writeNetworkDictCallBack'' which syntax is shown below.
UNS8 writeNetworkDictCallBack (CO_Data* d,
UNS8 nodeId,
UNS16 index,
UNS8 subIndex,
UNS8 count,
UNS8 dataType,
void *data,
SDOCallback_t Callback);
Meaning of function arguments:
'''d''' - pointer to local object dictionary structure
'''nodeId''' - ID of the device we want to send SDO
'''index''' - the index in the object dictionary where you want to write an entry
'''subIndex''' - the subindex of the Index. e.g. mostly subindex 0 is used to tell you how many valid entries you can find in this index. Look at the canopen standard for further information
'''count''' - number of bytes to be written
'''dataType''' - type of the data, use 0 for integers, real numbers and other values
'''data''' - pointer to the data
'''Callback''' - pointer to a function which is called after finishing the transfer
The SDO service is by definition confirmed. It means that SDO server sends response with result of the transfer after each SDO reception. This response has to be read by client to be sure that the data were written correctly. The result should be read in your function which pointer is given to the function ''writeNetworkDictCallBack'' as parameter ''callback''. The result of SDO transfer in such a function is read by CanFestival function ''getWriteResultNetworkDict''. This function has to be called after each SDO transmission because it releases line used to transfer. Header of this function is:
UNS8 getWriteResultNetworkDict (CO_Data* d, UNS8 nodeId, UNS32 * abortCode);
And meaning of function arguments is:
'''d''' - pointer to local object dictionary structure
'''nodeId''' - ID of the device we have sent SDO
'''abortCode''' - pointer to the variable where error code is written in case of error
The function can return one of these values according to the SDO transfer state:
'''SDO_FINISHED''' - data is available
'''SDO_ABORTED_RCV''' - Transfer failed. (abort SDO received)
'''SDO_ABORTED_INTERNAL''' - Transfer failed. Internal abort.
'''SDO_DOWNLOAD_IN_PROGRESS''' - Data not yet available
The function can be used in cycle waiting while return value is ''SDO_DOWNLOAD_IN_PROGRESS''. But the better solution is calling it in callback function from ''writeNetworkDictCallBack''. The callback is call after finishing the transfer.

===Using PDO service===

Using PDO service for data exchange is very easy in CanFestival. The most usual transmission type of PDOs is that they are transmitted after SYNC message. In this case it just has to be set up in objdictedit configuration and then it works, reads and stores values into mapped variables. After each PDO reception or transmission ''post_TPDO'' callback is called if used.
Sometimes it is necessary to send PDO from code without SYNC message reception. This is done by calling the function ''sendPDOevent'' with this syntax:
UNS8 sendPDOevent(CO_Data* d);
where ''d'' is the pointer to local object dictionary structure. This function sends all PDOs defined by 'objdictedit' and transmission type ''after event'' (0x255).

===Generating SYNC message===

If you want to set up local node to become the SYNC server you have to write some information to local OD. Here is an example of function which set up the SYNC messages generation:
/**
* This function initializes local canopen node to send SYNC message
* with given period.
* @param d - local object dictionary
* @param period - period of the SYNC message in us
*/
void synchro_setup(CO_Data *d, unsigned long period)
{
UNS32 SYNC_COBID = 0x40000080;
UNS32 SYNC_INTER = period;
UNS8 size = sizeof(UNS32);
writeLocalDict(d, 0x1006, 0x0, &SYNC_INTER, &size, RW);
writeLocalDict(d, 0x1005, 0x0, &SYNC_COBID, &size, RW);
}
According to CANopen specification ID of the SYNC message is 0x80.
After the setup it can be started by command ''startSYNC(CO_Data *d)'' and stopped by command ''stopSYNC(CO_Data *d)''.

===SDO and PDO example===

At the end I attach example of a function (''cpd_start()'') which starts some device communicating by CANopen. The ID of the device is given by the parameter. The other function (''cpd_checkSDO_start()'') is callback used to handle SDO transfer result. It is necessary to wait until one SDO transfer is finished before starting some other. Global variable ''cpd_init_step'' is used for counting actual step of SDO transfer. If some SDO transfer fails it is set to -1 and the startup process is terminated.
/**
* This function is given to the writeNetworkDict function as a callback.
* It checks the result of SDO transmition and after finishing the transmition
* it closes the transfer.
* @param d - local object disctionary
* @param nodeID - ID of the node which the local node is communicating with
*/
void cpd_checkSDO_start(CO_Data* d, UNS8 nodeId)
{
UNS32 abortCode;
if(getWriteResultNetworkDict (d, nodeId, &abortCode) != SDO_FINISHED) {
cpd_init_step = -1;
}
closeSDOtransfer(&canopen_Data, nodeId, SDO_CLIENT);
cpd_start(&canopen_Data, nodeId);
}

/**
* This function switch canopen device into operational state.
* @param d - local object dictionary
* @param nodeId - ID of the device
* return 0 - ok, -1 - failed
*/
int cpd_start(CO_Data *d, UNS8 nodeId)
{
UNS8 data8;
UNS16 data16;
UNS32 data32;
switch(cpd_init_step++) {
case 0:
masterSendNMTstateChange(d, nodeId, NMT_Start_Node);
s_PDO pdo;
cpd_controlword = 0;
pdo.cobId = 0x200 + nodeId;
int i = 0;
for(i = 0; i < 8; i++) {
pdo.data[i] = 0;
}
pdo.data[0] = 0;
pdo.data[1] = 0;
pdo.len = sizeof(pdo.data);
sendPDO(d, pdo, NOT_A_REQUEST);
cpd_controlword = 6;
pdo.cobId = 0x200 + nodeId;
for(i = 0; i < 8; i++) {
pdo.data[i] = 0;
}
pdo.data[0] = 7;
pdo.data[1] = 0;
pdo.len = sizeof(pdo.data);
sendPDO(d, pdo, NOT_A_REQUEST);
cpd_controlword = 0x0F;
pdo.cobId = 0x200 + nodeId;
for(i = 0; i < 8; i++) {
pdo.data[i] = 0;
}
pdo.data[0] = 0xF;
pdo.data[1] = 0;
pdo.len = sizeof(pdo.data);
sendPDO(d, pdo, NOT_A_REQUEST);

// Start operational mode
data8 = 0xFC;
writeNetworkDictCallBack(d, nodeId, 0x6060, 0x00, 1, 0, &data8, cpd_checkSDO_start);
break;
case 1:
// Check operation status
readNetworkDictCallback(d, nodeId, 0x6061, 0x00, 0, cpd_checkSDO_start);
break;
case 2:
// Setpoint specification
data16 = 0x0002;
writeNetworkDictCallBack(d, nodeId, 0x301B, 0x11, 2, 0, &data16, cpd_checkSDO_start);
break;
case 3:
canopen_init_result = 0;
cpd_init_step = 0;
break;
case -1:
canopen_init_result = -1;
cpd_init_step = 0;
break;
}
return 0;
}

===Emergency message===

New version of CanFestival is extended by EMCY messages support. There is callback added which can be set to point to your own EMCY message handler.This handler has to be a function with three parameters defined in this way:
void my_post_emcy(UNS8 nodeID, UNS16 errCode, UNS8 errReg)
After reception of an EMCY message this callback is called. The parameters keep information about node ID of the EMCY producer, error code and content of the error register.
To register your handler you have to set the callback in CanFestival initialization.
my_Data.post_emcy = my_post_emcy;

Boa5200 HOWTO

2007-11-04T15:25:48Z

Hamacl1: /* Emergency message */

==Introduction==
This document describes how to install and setup Linux and development environment for BOA5200 board.
Assume that you have a development machine (your PC) that you use for development and building your applications which you consequently want to get running and test on BOA5200.

==Serial line setting==
The easiest way to communicate with the board ,when there is no OS and remote shell running on it, is over serial line. Recommended serial communication program is minicom. Setup minicom as follows:

Baud Rate – 38400

Bits - 8

Parity – N

Stop Bits - 1

Hardware Flow Control:- No

Software Flow Control:- No

After the setup you will see Redboot> command prompt. Here you can enter Redboot`s commands.
Redboot is a simple boot manager bulit upon eCos real-time OS. For more details , see http://ecos.sourceware.org/ecos/docs-latest/redboot/redboot-guide.html.

==DHCP server setup==
Redboot supports BOOTP protocol which means that it is able to get network information(IP,netmask,gateway IP address,etc.) from DHCP server(provides BOOTP besides DHCP protocol). Install dhcp server (on debian: apt-get install dhcpd) on your development machine. Example of my dhcp configuration file /etc/dhcpd.conf:
# I have two ethernet interfaces:
# eth0 - Internet
# eth1 - connection to BOA5200 (IP= 192.168.10.1)
# I do not want to progate infos to 147.32.0.0 subnetwork
subnet 147.32.0.0 netmask 255.255.0.0 {
}

# private subnetwork
subnet 192.168.10.0 netmask 255.255.255.0 {
option broadcast-address 192.168.10.255;
option routers 192.168.10.1;
option subnet-mask 255.255.255.0;
default-lease-time 600;
max-lease-time 7200;

# settings for BOA5200
host BOA5200 {
hardware ethernet 00:08:f1:11:22:33;
fixed-address 192.168.10.2;
}
}

Start dhcp server and reboot the board. After booting it has assigned IP, netmask and gateway address:
+PHY0: AMD AM79C874
FEC eth0: 100Mb/Full Duplex
Ethernet eth0: MAC address 00:08:f1:11:22:33
IP: 192.168.10.2/255.255.255.0, Gateway: 192.168.10.1
Default server: 192.168.10.1

==TFTP server setup==
Redboot is able to load file from remote tftp server into memory. Tftp server is lanuched by inetd daemon when a new
connection comes.
Therefore add the following line into /etc/inetd.conf :
tftp dgram udp wait nobody /usr/sbin/tcpd /usr/sbin/in.tftpd

Default tftp root directory is /tftpboot. You can change it by calling in.tftpd with specified directory as a parameter.

===Alternative way for Ubuntu based distro===

1. Install tftpd and related packages.
sudo apt-get install xinetd tftpd tftp

2. Create /etc/xinetd.d/tftp and put this entry:

service tftp
{
protocol = udp
port = 69
socket_type = dgram
wait = yes
user = nobody
server = /usr/sbin/in.tftpd
server_args = /tftpboot
disable = no
}

3. Make /tftpboot directory

sudo mkdir /tftpboot
sudo chmod -R 777 /tftpboot
sudo chown -R nobody /tftpboot

4. Start tftpd through xinetd

sudo /etc/init.d/xinetd start

see [[http://www.example.com Installing and setting TFTPD in Ubuntu]]

==Tool chain==
Toolchain(gcc, ld, ...) for MPC5200 can be downloaded from ftp://rtime.felk.cvut.cz/MPC5200/gcc-powerpc-603e-linux-gnu-4.1.1-bin.tar.gz
Unpack the archive:

cd /
tar xvzf gcc-powerpc-603e-linux-gnu-4.1.1-bin.tar.gz

You can also create a debian package from archive and then install the package:
alien --to-deb gcc-powerpc-603e-linux-gnu-4.1.1-bin.tar.gz
Note: If you are not root, use fakeroot to run the command.

==Applying kernel patches==
It is recommended to use [http://linux.die.net/man/1/quilt quilt] tool to manage series of patches.

'''Mini-Howto:'''

Assuming kernel sources are in directory /usr/src/linux.

1. cd /usr/src/linux

2. mkdir patches

3. Copy all patches you want to apply to ''patches'' subdirectory

4. Create ''series'' file in ''patches'' subdirectory and write names of patch files each on separate line. The order
the patches are stated in the file is significant!! The patch on the first line will be applied first followed by others.

4. ''quilt push'' (''quilt pop'') - applies (unapplies) all patches in ''series'' file

==Building kernel==

'''2.4 kernel sources''' for MPC5200 can be found in ''eCos_Linux_boa5200/tgz'' directory on BOARD DOCUMENTATION CD or from ftp://rtime.felk.cvut.cz/MPC5200/kernel_2.4/linuxppc-2.4-boa5200-release_2006_05_10.tgz.

'''2.6 Kernel sources''' for MPC5200 can be downloaded from ftp://rtime.felk.cvut.cz/MPC5200/linuxppc-2.6.18-1_AM.tar.gz.
Default kernel configuration file is ftp://rtime.felk.cvut.cz/MPC5200/config-2.6.18-1_AM.
Do not forget to set ARCH and CROSS_COMPILE variables to this values in Makefile:
ARCH=ppc
CROSS_COMPILE=powerpc-603e-linux-gnu-

After compilation a built image is placed into arch/ppc/boot/image directory.

The following commnad will install modules into ''<directory>''/lib/modules/...
make INSTALL_MOD_PATH=''<directory>'' modules_install

'''Recommendation:'''

1. Make the building directory linuxppc-2.6.18-1_AM_build, where object files will be placed, outside the origin source directory linuxppc-2.6.18-1_AM

mkdir linuxppc-2.6.18-1_AM_build

2.
cd linuxppc-2.6.18-1_AM
linuxppc-2.6.18-1_AM directory must be clean i.e. no make, make menuconfig executed from this directory
before!

3.
make O=../linuxppc-2.6.18-1_AM_build menuconfig
kernel config file (.config) will be created in linuxppc-2.6.18-1_AM_build

Next time, always run make menuconfig always from the building directory, i.e. linuxppc-2.6.18-1_AM_build

4.
cd linuxppc-2.6.18-1_AM_build

5.
Download ftp://rtime.felk.cvut.cz/MPC5200/GNUmakefile

6.
Edit GNUmakefile and change paths in KERNELSRC and KERNELOUTPUT variables

7.
make && make modules_install

== Loading kernel ==

You can test your new image on the board as follows:
# load kernel image from tftp server into memory
RedBoot> load zImage.elf

# execute image; root directory (/) is on flash memory
RedBoot> exec
If you want to load the kernel from different TFTP server than the one provided by DHCP, you can use the following command to set the IP address of your server:
RedBoot> ip_address -h 147.32.86.<xxx>

'''CAUTION:''' you must boot the kernel by RedBoot release at least 2007_02_01 otherwise it will not run! So you must load into RAM and then run the appropriate RedBoot image (or replace/update its image on flash with the new one - see
the next section) and after then you can execute kernel image.

==Updating RedBoot==
Download ftp://rtime.felk.cvut.cz/MPC5200/MPC5200-2007.02.01-redbootROMRAM.srec

'''!!! Warning: File names are case-sensitive !!!'''

# load RedBoot image from tftp server into memory at the address 0x100000
RedBoot>lo -b 0x100000 MPC5200-2007.02.01-redbootROMRAM.srec

'''!!! Warning: File names are case-sensitive !!!'''

# write image in flash memory
RedBoot>fi cr RedBoot
RedBoot>reset

If upgrade fails you can fallback to ROM Redboot image by typing 'A&M:'

If image of ROMRAM version of RedBoot with name "RedBoot" (case sensitive!!) is not found in FLASH minimal version of ROM RedBoot is started. This version does not support many services like TFTP protocol and FLASH management. To download ROMRAM version of RedBoot to FLASH it is necessary to follow these steps:

Load RAM version of RedBoot to BOA using xmodem (the image file MPC5200-2006.05.10-redbootRAM.srec is placed on BOA original CD):
RedBoot> lo -m xmodem

When finished RedBoot should answer with something like that:

CEntry point: 0x00080100, address range: 0x00080000-0x000bea04
xyzModem - CRC mode, 5763(SOH)/0(STX)/0(CAN) packets, 1 retries

Then start the RedBoot:
RedBoot> go

RAM RedBoot should start now. Download the new version of ROMRAM RedBoot to FLASH according to the steps above.

==NFS-root setup==

During the development phase of application it must be tested many times. However, it is annoying to copy several application files to flash memory every time. The practical solution is to mount via NFS working directory or whole root directory from the point of OS running on the board.

You can download already prepared root directory from ftp://rtime.felk.cvut.cz/MPC5200/MPC5200_root_070321.tar.gz

To export /var/MPC5200_root directory via NFS add the following line to /etc/exports:

/var/MPC5200_root 192.168.10.0/255.255.255.0(rw,sync,no_root_squash)

Then run command 'exportfs -ra' so that the change take an effect.

If you want MPC5200 to be mount as root directory instead of that one in flash memory:
# load kernel image from tftp server into memory
RedBoot> load zImage.elf
# execute kernel image with information where to
# find root directory in parameter string
RedBoot> ex -c "root=/dev/nfs rw nfsroot=192.168.10.1:/var/MPC5200_root ip=dhcp"

NOTE: exportfs is a part of knfs package for debian systems (ubuntu,...)

== Login with telnet ==
telnet <ip address of boa>
Log in as root, ask me for the password. --[[User:Sojka|Sojka]] 20:42, 21 March 2007 (CET)
==Setting up BOA5200==

Use 'fconfig' command (see http://ecos.sourceware.org/ecos/docs-latest/redboot/persistent-state-flash.html manual) to set up BOA5200 configuration. Recommended configuration:

Run script at boot: true
Boot script:
load zImage.elf
ex -c "root=/dev/nfs rw nfsroot=192.168.123.254:/var/MPC5200_root ip=dhcp"
Boot script timeout (1000ms resolution): 10
Use BOOTP for network configuration: true
Default server IP address: IP address of your computer
FEC Network hardware address [MAC]: choose MAC address of the unit (example: 0x00:0x00:0x00:0x00:0x00:0x02)
GDB connection port: 9000
Force console for special debug messages: false
Network debug at boot time: false
Update RedBoot non-volatile configuration - continue (y/n)? y

==Socketcan==

Prior to compiling linux kernel with socketcan driver, it is necessary to [http://rtime.felk.cvut.cz/hw/index.php/HOWTO#Applying_kernel_patches apply kernel patches] , which can be found in [http://rtime.felk.cvut.cz/repos/boa5200-linux/patches/ DARCS repository]

To set up can interface, it is necessary to configure the communication speed first and then bring the interface up. Communication speed can be set up using following command (for can0 interface):

echo 660000 >/sys/class/net/can0/can_baudrate

The constant 660000 was found experimentally, driver seems to calculate the transmission speed improperly. To bring up the can network interface, use the same command as with any other network interface, i.e.

ifconfig can0 up

The most comfortable way of setting up both can interfaces upon startup of system is to place following script to /etc/init.d/ (name it 'can', for example)

echo 660000 >/sys/class/net/can0/can_baudrate
echo 660000 >/sys/class/net/can1/can_baudrate
ifconfig can0 up
ifconfig can1 up

==CanFestival==

===Obtaining and building CanFestival===

CanFestival driver source can be downloaded from. The primary way how to do it is to check out the source directory from CanFestival CVS by these steps:
cvs -d:pserver:anonymous@lolitech.dyndns.org:/canfestival login
(type return, without entering a password)
The system will respond:
Logging in to :pserver:anonymous@lolitech.dyndns.org:2401/canfestival
Then, enter:
cvs -z3 -d:pserver:anonymous@lolitech.dyndns.org:/canfestival co -P CanFestival-3
Then insert CanFestival folder and run this commands:
./configure --timers=unix --can=socket --cc=powerpc-603e-linux-gnu-gcc --arch=ppc --os=linux --target=unix
make
make install
Building of CanFestival will produce some libraries and copy them to /usr/powerpc-603e-linux-gnu/lib folder.

===Setting up local CANopen node===

CanFestival source includes tool called ''objdictedit''. This program has graphical user interface and serves to creating configuration of the CANopen node of application we develop. It is started by command ''objdictedit''. Using this program you can create the object dictionary for the CanFestival. Mainly it is necessary to set up all SDO and PDO, the node has to send and receive. To each PDO you have to define more things - PDO receive or transmit, variable to be mapped and variable mapping. The variable will then be used in application code to exchange data between CanFestival driver and application. If you set up PDOs here they will be sent and received automatically and the values will be stored into mapped variable. Setting up SDO means that you can use it in your application, but if you want to send it, it has to be done in code.
After creating this basic configuration you have to build the dictionary which results into to files with extensions .h and .c. You have to link these files with your application.

===Initializing and starting CanFestival===

To explain how to use CanFestival I include some code examples. It supposes node configuration generated by ''objdictedit'' which name is ''canopen''. It is then used as prefix of automatically generated functions and variables (''canopen_Data'' is for example object dictionary used by CanFestival).
Header ''canfestival.h'' has to be included. For start using CanFestival it is necessary to load dynamic library with CAN bus driver API created while compiling CanFestival source. In the example SocketCan driver is used to access CAN bus.
if(!LoadCanDriver("libcanfestival_can_socket.so")) {
exit -1;
}
Then you have to open CAN device. Parameters of the communication have to be prepared in structure of type ''s_Board''. In this case CAN is set to use device ''can1'' and baudrate 1Mbps. Handler of the bus is then stored to variable of type ''CAN_HANDLE''.
/**
* CAN board definition.
* Device name can1, baudrate 1M
*/
s_BOARD canopen_board = {"1", "1000"};

CAN_HANDLE canopen_handle;

if(!(canopen_handle = canOpen(&canopen_board, &canopen_Data))) {
exit -1;
}
CanFestival implements callbacks to some events like change of state or message reception. There are pointers to callback functions in ''canopen_Data'' structure. You can assign your own functions to these pointers or leave them unused.
canopen_Data.initialisation = canopen_initialisation;
canopen_Data.preOperational = canopen_preOperational;
canopen_Data.operational = canopen_operational;
canopen_Data.post_sync = canopen_post_sync;
canopen_Data.post_TPDO = canopen_post_TPDO;
canopen_Data.stopped = canopen_stopped;
After setting up these few things you have to call function ''StartTimerLoop'' which initializes CanFestival timers. As an argument you have to insert pointer to the first function you want to proceed after starting the timers.
StartTimerLoop(&initNode);
Here is an example of such a function. It sets local node ID to 1 and bring the node to operation state. Callback functions are called after changing state if used.
void initNode(CO_Data * d, UNS32 id)
{
setNodeId(&canopen_Data, 0x01);
setState(&canopen_Data, Initialisation);
setState(&canopen_Data, Operational);
}

===Stopping CanFestival===

After finishing work with CANopen it is good to stop the communication and timers and close the device. It is done by these few functions.
setState(&canopen_Data, Stopped);
StopTimerLoop();
canClose(&canopen_Data);
canopen_handle = NULL;

===Writing to Object dictionary===

CANopen devices and all network services of each node are configured by writing to device object dictionary (OD). It is different while writing to local OD or OD of some network device.
====Writing to local OD====
Function ''WriteLocalDict'' is used for writing to OD of local node managed by CanFestival.
UNS32 writeLocalDict( CO_Data* d,
UNS16 wIndex,
UNS8 bSubindex,
void * pSourceData,
UNS8 * pExpectedSize,
UNS8 checkAccess);
Meaning of function arguments:
'''d''' - pointer to local object dictionary structure
'''wIndex''' - the index in the object dictionary where you want to write an entry
'''bSubindex''' - the subindex of the Index. e.g. mostly subindex 0 is used to tell you how many valid entries you can find in this index. Look at the canopen standard for further information
'''pbSourceData''' - pointer to the variable that holds the value that should be copied into the object dictionary
'''pExpectedSize''' - pointer to variable with size of the data to be written
'''CheckAccess''' - if other than 0, do not read if the data is Read Only or Constant

====Writing to network OD====

It is necessary to use SDO service for writing data to OD of some network device. Each CANopen device has at least one SDO server. It means that it is able to receive SDOs with one ID and answer by SDOs with another ID. It is usual that the server listen for SDOs with ID 0x600 + ID of the node and transmits SDOs of ID 0x580 + node ID. Each SDO we want to use has to be defined while creating node configuration by ''objdictedit''. Then the SDO is sent by calling appropriate function. The best is to use function ''writeNetworkDictCallBack'' which syntax is shown below.
UNS8 writeNetworkDictCallBack (CO_Data* d,
UNS8 nodeId,
UNS16 index,
UNS8 subIndex,
UNS8 count,
UNS8 dataType,
void *data,
SDOCallback_t Callback);
Meaning of function arguments:
'''d''' - pointer to local object dictionary structure
'''nodeId''' - ID of the device we want to send SDO
'''index''' - the index in the object dictionary where you want to write an entry
'''subIndex''' - the subindex of the Index. e.g. mostly subindex 0 is used to tell you how many valid entries you can find in this index. Look at the canopen standard for further information
'''count''' - number of bytes to be written
'''dataType''' - type of the data, use 0 for integers, real numbers and other values
'''data''' - pointer to the data
'''Callback''' - pointer to a function which is called after finishing the transfer
The SDO service is by definition confirmed. It means that SDO server sends response with result of the transfer after each SDO reception. This response has to be read by client to be sure that the data were written correctly. The result should be read in your function which pointer is given to the function ''writeNetworkDictCallBack'' as parameter ''callback''. The result of SDO transfer in such a function is read by CanFestival function ''getWriteResultNetworkDict''. This function has to be called after each SDO transmission because it releases line used to transfer. Header of this function is:
UNS8 getWriteResultNetworkDict (CO_Data* d, UNS8 nodeId, UNS32 * abortCode);
And meaning of function arguments is:
'''d''' - pointer to local object dictionary structure
'''nodeId''' - ID of the device we have sent SDO
'''abortCode''' - pointer to the variable where error code is written in case of error
The function can return one of these values according to the SDO transfer state:
'''SDO_FINISHED''' - data is available
'''SDO_ABORTED_RCV''' - Transfer failed. (abort SDO received)
'''SDO_ABORTED_INTERNAL''' - Transfer failed. Internal abort.
'''SDO_DOWNLOAD_IN_PROGRESS''' - Data not yet available
The function can be used in cycle waiting while return value is ''SDO_DOWNLOAD_IN_PROGRESS''. But the better solution is calling it in callback function from ''writeNetworkDictCallBack''. The callback is call after finishing the transfer.

===Using PDO service===

Using PDO service for data exchange is very easy in CanFestival. The most usual transmission type of PDOs is that they are transmitted after SYNC message. In this case it just has to be set up in objdictedit configuration and then it works, reads and stores values into mapped variables. After each PDO reception or transmission ''post_TPDO'' callback is called if used.
Sometimes it is necessary to send PDO from code without SYNC message reception. This is very inconsistent in CanFestival version 3. There are some functions which should solve this situation but they are commented and some other solution is promised to be done in the future. For now I have done it by using function sendPDO which syntax is:
UNS8 sendPDO (CO_Data* d, s_PDO pdo, UNS8 request);
And meaning of function arguments is:
'''d''' - pointer to local object dictionary structure
'''pdo''' - structure with PDO message
'''request''' - REQUEST (request for sending PDO) or NOT_A_REQUEST (normal PDO)
PDO message has to be created using structure s_PDO which meaning is clear:
typedef struct struct_s_PDO {
UNS32 cobId; /* COB-ID */
UNS8 len; /* Number of data transmitted (in data[]) */
UNS8 data[8]; /* Contain the data */
} s_PDO;

===Generating SYNC message===

If you want to set up local node to become the SYNC server you have to write some information to local OD. Here is an example of function which set up the SYNC messages generation:
/**
* This function initializes local canopen node to send SYNC message
* with given period.
* @param d - local object dictionary
* @param period - period of the SYNC message in us
*/
void synchro_setup(CO_Data *d, unsigned long period)
{
UNS32 SYNC_COBID = 0x40000080;
UNS32 SYNC_INTER = period;
UNS8 size = sizeof(UNS32);
writeLocalDict(d, 0x1006, 0x0, &SYNC_INTER, &size, RW);
writeLocalDict(d, 0x1005, 0x0, &SYNC_COBID, &size, RW);
}
According to CANopen specification ID of the SYNC message is 0x80.
After the setup it can be started by command ''startSYNC(CO_Data *d)'' and stopped by command ''stopSYNC(CO_Data *d)''.

===SDO and PDO example===

At the end I attach example of a function (''cpd_start()'') which starts some device communicating by CANopen. The ID of the device is given by the parameter. The other function (''cpd_checkSDO_start()'') is callback used to handle SDO transfer result. It is necessary to wait until one SDO transfer is finished before starting some other. Global variable ''cpd_init_step'' is used for counting actual step of SDO transfer. If some SDO transfer fails it is set to -1 and the startup process is terminated.
/**
* This function is given to the writeNetworkDict function as a callback.
* It checks the result of SDO transmition and after finishing the transmition
* it closes the transfer.
* @param d - local object disctionary
* @param nodeID - ID of the node which the local node is communicating with
*/
void cpd_checkSDO_start(CO_Data* d, UNS8 nodeId)
{
UNS32 abortCode;
if(getWriteResultNetworkDict (d, nodeId, &abortCode) != SDO_FINISHED) {
cpd_init_step = -1;
}
closeSDOtransfer(&canopen_Data, nodeId, SDO_CLIENT);
cpd_start(&canopen_Data, nodeId);
}

/**
* This function switch canopen device into operational state.
* @param d - local object dictionary
* @param nodeId - ID of the device
* return 0 - ok, -1 - failed
*/
int cpd_start(CO_Data *d, UNS8 nodeId)
{
UNS8 data8;
UNS16 data16;
UNS32 data32;
switch(cpd_init_step++) {
case 0:
masterSendNMTstateChange(d, nodeId, NMT_Start_Node);
s_PDO pdo;
cpd_controlword = 0;
pdo.cobId = 0x200 + nodeId;
int i = 0;
for(i = 0; i < 8; i++) {
pdo.data[i] = 0;
}
pdo.data[0] = 0;
pdo.data[1] = 0;
pdo.len = sizeof(pdo.data);
sendPDO(d, pdo, NOT_A_REQUEST);
cpd_controlword = 6;
pdo.cobId = 0x200 + nodeId;
for(i = 0; i < 8; i++) {
pdo.data[i] = 0;
}
pdo.data[0] = 7;
pdo.data[1] = 0;
pdo.len = sizeof(pdo.data);
sendPDO(d, pdo, NOT_A_REQUEST);
cpd_controlword = 0x0F;
pdo.cobId = 0x200 + nodeId;
for(i = 0; i < 8; i++) {
pdo.data[i] = 0;
}
pdo.data[0] = 0xF;
pdo.data[1] = 0;
pdo.len = sizeof(pdo.data);
sendPDO(d, pdo, NOT_A_REQUEST);

// Start operational mode
data8 = 0xFC;
writeNetworkDictCallBack(d, nodeId, 0x6060, 0x00, 1, 0, &data8, cpd_checkSDO_start);
break;
case 1:
// Check operation status
readNetworkDictCallback(d, nodeId, 0x6061, 0x00, 0, cpd_checkSDO_start);
break;
case 2:
// Setpoint specification
data16 = 0x0002;
writeNetworkDictCallBack(d, nodeId, 0x301B, 0x11, 2, 0, &data16, cpd_checkSDO_start);
break;
case 3:
canopen_init_result = 0;
cpd_init_step = 0;
break;
case -1:
canopen_init_result = -1;
cpd_init_step = 0;
break;
}
return 0;
}

===Emergency message===

New version of CanFestival is extended by EMCY messages support. There is callback added which can be set to point to your own EMCY message handler.This handler has to be a function with three parameters defined in this way:
void my_post_emcy(UNS8 nodeID, UNS16 errCode, UNS8 errReg)
After reception of an EMCY message this callback is called. The parameters keep information about node ID of the EMCY producer, error code and content of the error register.
To register your handler you have to set the callback in CanFestival initialization.
my_Data.post_emcy = my_post_emcy;

Boa5200

2007-10-23T15:36:53Z

Hamacl1: /* Work Progress */

== Documentation ==

* [ftp://rtime.felk.cvut.cz/MPC5200 Original documentation]
* [http://ecos.sourceware.org/ecos/docs-latest/redboot/redboot-guide.html Redboot documentace] - Redboot howto na CD k desce je neaktualny.
* [[HOWTO]]

== Work Progress ==
* CanFestival tutorial added into [[HOWTO]] --[[User:Hamacl1|Hamacl1]] 17:36, 23 October 2007 (CEST)

* New version of the root file-system. Telnet server is started during boot and tcpdump and strace was added from Debian. --[[User:Sojka|Sojka]] 20:40, 21 March 2007 (CET)
* Added links to darcs repository --[[User:Sojka|Sojka]] 16:42, 7 March 2007 (CET)
* few edits in HOWTO, successful test of TFTP boot, NFS from desktop OK --[[User:Zidekm|Zidekm]] 19:47, 19 February 2007 (CET)
* TODO - instalace CAN driveru
*HowTo k MPC5200 - done
--[[User:Molnam1|Molnam1]] 17:32, 9 February 2007 (CET)
*build toolchain+ kernel 2.6.18(Pavel P.); dhcp,tftp, root over nfs, testy (Martin M.) - done
--[[User:Molnam1|Molnam1]] 17:00, 6 February 2007 (CET)
* Added this section. The purpose is to keep people in sync with other's work. You should add here the brief description of your daily results. Use signature icon to put your name and date here. --[[User:Sojka|Sojka]] 15:18, 6 February 2007 (CET)

== Darcs repository ==

You can [http://rtime.felk.cvut.cz/darcs/darcsweb.cgi?r=boa5200-linux browse the repository] or you can download it by:
darcs get <login>@rtime.felk.cvut.cz:/var/repos/boa5200-linux
or
darcs get http://rtime.felk.cvut.cz/repos/boa5200-linux

== Úkoly ==

Vždy když je úkol splněný přeškrtněte ho a případně k němu napište komentář.

* Carrier board - '''Libor'''
** Pridat NAND flash

* Linux 2.6 - '''Pavel'''
** Žižka
** <strike>A&Micro</strike> - poslali patch k 2.6 a novou verzi Redbootu, otestovano - OK
** <strike>DENX </strike>('''Martin M.''') - distribuce primarne urcena pro MPC5200Lite desku; pokus na desce BOA5200 byl neuspesny; z vyse uvedenych duvodu ani nema cenu resit
* Linux 2.4 - '''Martin Ž.'''
** <strike>Překopilování 2.4</strike> - nepodstatne, viz. rozchozeni jadra 2.6, kompilace 2.6 OK
** <strike>TFTP boot</strike> OK
** <strike>Zkouška aplikace (Hello world)</strike> - OK

* <strike>SocketCAN</strike> - '''Martin Ž.''' (pomůže Pavel) - OK

* LinCAN - Petera

* CANopen
** <strike>Boa5200 master</strike> ('''Hamáek''') - Canfestival tutorial added into [[HOWTO]]
** H8S slave ('''Benda''')
** ?? slave ('''Hamáek''')

* Toolchain + User-space ('''Michal + Martin Ž.''')
** GLIBC
** BusyBox
** PTXdist

* Build sandbox ('''Michal''')

== Budoucí rozšíření ==

* Při výrobě nových DPS pro BOA5200 zvážit přidání USB hosta. Zapojení dle: [http://www.synertronixx.de/download/AppNotes/AN009.pdf AN009] - AN pro zapojení USB host na datovou sběrnici.

Boa5200

2007-10-23T15:34:37Z

Hamacl1: /* koly */

== Documentation ==

* [ftp://rtime.felk.cvut.cz/MPC5200 Original documentation]
* [http://ecos.sourceware.org/ecos/docs-latest/redboot/redboot-guide.html Redboot documentace] - Redboot howto na CD k desce je neaktualny.
* [[HOWTO]]

== Work Progress ==
* New version of the root file-system. Telnet server is started during boot and tcpdump and strace was added from Debian. --[[User:Sojka|Sojka]] 20:40, 21 March 2007 (CET)
* Added links to darcs repository --[[User:Sojka|Sojka]] 16:42, 7 March 2007 (CET)
* few edits in HOWTO, successful test of TFTP boot, NFS from desktop OK --[[User:Zidekm|Zidekm]] 19:47, 19 February 2007 (CET)
* TODO - instalace CAN driveru
*HowTo k MPC5200 - done
--[[User:Molnam1|Molnam1]] 17:32, 9 February 2007 (CET)
*build toolchain+ kernel 2.6.18(Pavel P.); dhcp,tftp, root over nfs, testy (Martin M.) - done
--[[User:Molnam1|Molnam1]] 17:00, 6 February 2007 (CET)
* Added this section. The purpose is to keep people in sync with other's work. You should add here the brief description of your daily results. Use signature icon to put your name and date here. --[[User:Sojka|Sojka]] 15:18, 6 February 2007 (CET)

== Darcs repository ==

You can [http://rtime.felk.cvut.cz/darcs/darcsweb.cgi?r=boa5200-linux browse the repository] or you can download it by:
darcs get <login>@rtime.felk.cvut.cz:/var/repos/boa5200-linux
or
darcs get http://rtime.felk.cvut.cz/repos/boa5200-linux

== Úkoly ==

Vždy když je úkol splněný přeškrtněte ho a případně k němu napište komentář.

* Carrier board - '''Libor'''
** Pridat NAND flash

* Linux 2.6 - '''Pavel'''
** Žižka
** <strike>A&Micro</strike> - poslali patch k 2.6 a novou verzi Redbootu, otestovano - OK
** <strike>DENX </strike>('''Martin M.''') - distribuce primarne urcena pro MPC5200Lite desku; pokus na desce BOA5200 byl neuspesny; z vyse uvedenych duvodu ani nema cenu resit
* Linux 2.4 - '''Martin Ž.'''
** <strike>Překopilování 2.4</strike> - nepodstatne, viz. rozchozeni jadra 2.6, kompilace 2.6 OK
** <strike>TFTP boot</strike> OK
** <strike>Zkouška aplikace (Hello world)</strike> - OK

* <strike>SocketCAN</strike> - '''Martin Ž.''' (pomůže Pavel) - OK

* LinCAN - Petera

* CANopen
** <strike>Boa5200 master</strike> ('''Hamáek''') - Canfestival tutorial added into [[HOWTO]]
** H8S slave ('''Benda''')
** ?? slave ('''Hamáek''')

* Toolchain + User-space ('''Michal + Martin Ž.''')
** GLIBC
** BusyBox
** PTXdist

* Build sandbox ('''Michal''')

== Budoucí rozšíření ==

* Při výrobě nových DPS pro BOA5200 zvážit přidání USB hosta. Zapojení dle: [http://www.synertronixx.de/download/AppNotes/AN009.pdf AN009] - AN pro zapojení USB host na datovou sběrnici.

Boa5200 HOWTO

2007-10-23T15:31:21Z

Hamacl1: /* CanFestival */

==Introduction==
This document describes how to install and setup Linux and development environment for BOA5200 board.
Assume that you have a development machine (your PC) that you use for development and building your applications which you consequently want to get running and test on BOA5200.

==Serial line setting==
The easiest way to communicate with the board ,when there is no OS and remote shell running on it, is over serial line. Recommended serial communication program is minicom. Setup minicom as follows:

Baud Rate – 38400

Bits - 8

Parity – N

Stop Bits - 1

Hardware Flow Control:- No

Software Flow Control:- No

After the setup you will see Redboot> command prompt. Here you can enter Redboot`s commands.
Redboot is a simple boot manager bulit upon eCos real-time OS. For more details , see http://ecos.sourceware.org/ecos/docs-latest/redboot/redboot-guide.html.

==DHCP server setup==
Redboot supports BOOTP protocol which means that it is able to get network information(IP,netmask,gateway IP address,etc.) from DHCP server(provides BOOTP besides DHCP protocol). Install dhcp server (on debian: apt-get install dhcpd) on your development machine. Example of my dhcp configuration file /etc/dhcpd.conf:
# I have two ethernet interfaces:
# eth0 - Internet
# eth1 - connection to BOA5200 (IP= 192.168.10.1)
# I do not want to progate infos to 147.32.0.0 subnetwork
subnet 147.32.0.0 netmask 255.255.0.0 {
}

# private subnetwork
subnet 192.168.10.0 netmask 255.255.255.0 {
option broadcast-address 192.168.10.255;
option routers 192.168.10.1;
option subnet-mask 255.255.255.0;
default-lease-time 600;
max-lease-time 7200;

# settings for BOA5200
host BOA5200 {
hardware ethernet 00:08:f1:11:22:33;
fixed-address 192.168.10.2;
}
}

Start dhcp server and reboot the board. After booting it has assigned IP, netmask and gateway address:
+PHY0: AMD AM79C874
FEC eth0: 100Mb/Full Duplex
Ethernet eth0: MAC address 00:08:f1:11:22:33
IP: 192.168.10.2/255.255.255.0, Gateway: 192.168.10.1
Default server: 192.168.10.1

==TFTP server setup==
Redboot is able to load file from remote tftp server into memory. Tftp server is lanuched by inetd daemon when a new
connection comes.
Therefore add the following line into /etc/inetd.conf :
tftp dgram udp wait nobody /usr/sbin/tcpd /usr/sbin/in.tftpd

Default tftp root directory is /tftpboot. You can change it by calling in.tftpd with specified directory as a parameter.

===Alternative way for Ubuntu based distro===

1. Install tftpd and related packages.
sudo apt-get install xinetd tftpd tftp

2. Create /etc/xinetd.d/tftp and put this entry:

service tftp
{
protocol = udp
port = 69
socket_type = dgram
wait = yes
user = nobody
server = /usr/sbin/in.tftpd
server_args = /tftpboot
disable = no
}

3. Make /tftpboot directory

sudo mkdir /tftpboot
sudo chmod -R 777 /tftpboot
sudo chown -R nobody /tftpboot

4. Start tftpd through xinetd

sudo /etc/init.d/xinetd start

see [[http://www.example.com Installing and setting TFTPD in Ubuntu]]

==Tool chain==
Toolchain(gcc, ld, ...) for MPC5200 can be downloaded from ftp://rtime.felk.cvut.cz/MPC5200/gcc-powerpc-603e-linux-gnu-4.1.1-bin.tar.gz
Unpack the archive:

cd /
tar xvzf gcc-powerpc-603e-linux-gnu-4.1.1-bin.tar.gz

You can also create a debian package from archive and then install the package:
alien --to-deb gcc-powerpc-603e-linux-gnu-4.1.1-bin.tar.gz
Note: If you are not root, use fakeroot to run the command.

==Applying kernel patches==
It is recommended to use [http://linux.die.net/man/1/quilt quilt] tool to manage series of patches.

'''Mini-Howto:'''

Assuming kernel sources are in directory /usr/src/linux.

1. cd /usr/src/linux

2. mkdir patches

3. Copy all patches you want to apply to ''patches'' subdirectory

4. Create ''series'' file in ''patches'' subdirectory and write names of patch files each on separate line. The order
the patches are stated in the file is significant!! The patch on the first line will be applied first followed by others.

4. ''quilt push'' (''quilt pop'') - applies (unapplies) all patches in ''series'' file

==Building kernel==

'''2.4 kernel sources''' for MPC5200 can be found in ''eCos_Linux_boa5200/tgz'' directory on BOARD DOCUMENTATION CD or from ftp://rtime.felk.cvut.cz/MPC5200/kernel_2.4/linuxppc-2.4-boa5200-release_2006_05_10.tgz.

'''2.6 Kernel sources''' for MPC5200 can be downloaded from ftp://rtime.felk.cvut.cz/MPC5200/linuxppc-2.6.18-1_AM.tar.gz.
Default kernel configuration file is ftp://rtime.felk.cvut.cz/MPC5200/config-2.6.18-1_AM.
Do not forget to set ARCH and CROSS_COMPILE variables to this values in Makefile:
ARCH=ppc
CROSS_COMPILE=powerpc-603e-linux-gnu-

After compilation a built image is placed into arch/ppc/boot/image directory.

The following commnad will install modules into ''<directory>''/lib/modules/...
make INSTALL_MOD_PATH=''<directory>'' modules_install

'''Recommendation:'''

1. Make the building directory linuxppc-2.6.18-1_AM_build, where object files will be placed, outside the origin source directory linuxppc-2.6.18-1_AM

mkdir linuxppc-2.6.18-1_AM_build

2.
cd linuxppc-2.6.18-1_AM
linuxppc-2.6.18-1_AM directory must be clean i.e. no make, make menuconfig executed from this directory
before!

3.
make O=../linuxppc-2.6.18-1_AM_build menuconfig
kernel config file (.config) will be created in linuxppc-2.6.18-1_AM_build

Next time, always run make menuconfig always from the building directory, i.e. linuxppc-2.6.18-1_AM_build

4.
cd linuxppc-2.6.18-1_AM_build

5.
Download ftp://rtime.felk.cvut.cz/MPC5200/GNUmakefile

6.
Edit GNUmakefile and change paths in KERNELSRC and KERNELOUTPUT variables

7.
make && make modules_install

== Loading kernel ==

You can test your new image on the board as follows:
# load kernel image from tftp server into memory
RedBoot> load zImage.elf

# execute image; root directory (/) is on flash memory
RedBoot> exec
If you want to load the kernel from different TFTP server than the one provided by DHCP, you can use the following command to set the IP address of your server:
RedBoot> ip_address -h 147.32.86.<xxx>

'''CAUTION:''' you must boot the kernel by RedBoot release at least 2007_02_01 otherwise it will not run! So you must load into RAM and then run the appropriate RedBoot image (or replace/update its image on flash with the new one - see
the next section) and after then you can execute kernel image.

==Updating RedBoot==
Download ftp://rtime.felk.cvut.cz/MPC5200/MPC5200-2007.02.01-redbootROMRAM.srec

'''!!! Warning: File names are case-sensitive !!!'''

# load RedBoot image from tftp server into memory at the address 0x100000
RedBoot>lo -b 0x100000 MPC5200-2007.02.01-redbootROMRAM.srec

'''!!! Warning: File names are case-sensitive !!!'''

# write image in flash memory
RedBoot>fi cr RedBoot
RedBoot>reset

If upgrade fails you can fallback to ROM Redboot image by typing 'A&M:'

If image of ROMRAM version of RedBoot with name "RedBoot" (case sensitive!!) is not found in FLASH minimal version of ROM RedBoot is started. This version does not support many services like TFTP protocol and FLASH management. To download ROMRAM version of RedBoot to FLASH it is necessary to follow these steps:

Load RAM version of RedBoot to BOA using xmodem (the image file MPC5200-2006.05.10-redbootRAM.srec is placed on BOA original CD):
RedBoot> lo -m xmodem

When finished RedBoot should answer with something like that:

CEntry point: 0x00080100, address range: 0x00080000-0x000bea04
xyzModem - CRC mode, 5763(SOH)/0(STX)/0(CAN) packets, 1 retries

Then start the RedBoot:
RedBoot> go

RAM RedBoot should start now. Download the new version of ROMRAM RedBoot to FLASH according to the steps above.

==NFS-root setup==

During the development phase of application it must be tested many times. However, it is annoying to copy several application files to flash memory every time. The practical solution is to mount via NFS working directory or whole root directory from the point of OS running on the board.

You can download already prepared root directory from ftp://rtime.felk.cvut.cz/MPC5200/MPC5200_root_070321.tar.gz

To export /var/MPC5200_root directory via NFS add the following line to /etc/exports:

/var/MPC5200_root 192.168.10.0/255.255.255.0(rw,sync,no_root_squash)

Then run command 'exportfs -ra' so that the change take an effect.

If you want MPC5200 to be mount as root directory instead of that one in flash memory:
# load kernel image from tftp server into memory
RedBoot> load zImage.elf
# execute kernel image with information where to
# find root directory in parameter string
RedBoot> ex -c "root=/dev/nfs rw nfsroot=192.168.10.1:/var/MPC5200_root ip=dhcp"

NOTE: exportfs is a part of knfs package for debian systems (ubuntu,...)

== Login with telnet ==
telnet <ip address of boa>
Log in as root, ask me for the password. --[[User:Sojka|Sojka]] 20:42, 21 March 2007 (CET)
==Setting up BOA5200==

Use 'fconfig' command (see http://ecos.sourceware.org/ecos/docs-latest/redboot/persistent-state-flash.html manual) to set up BOA5200 configuration. Recommended configuration:

Run script at boot: true
Boot script:
load zImage.elf
ex -c "root=/dev/nfs rw nfsroot=192.168.123.254:/var/MPC5200_root ip=dhcp"
Boot script timeout (1000ms resolution): 10
Use BOOTP for network configuration: true
Default server IP address: IP address of your computer
FEC Network hardware address [MAC]: choose MAC address of the unit (example: 0x00:0x00:0x00:0x00:0x00:0x02)
GDB connection port: 9000
Force console for special debug messages: false
Network debug at boot time: false
Update RedBoot non-volatile configuration - continue (y/n)? y

==Socketcan==

Prior to compiling linux kernel with socketcan driver, it is necessary to [http://rtime.felk.cvut.cz/hw/index.php/HOWTO#Applying_kernel_patches apply kernel patches] , which can be found in [http://rtime.felk.cvut.cz/repos/boa5200-linux/patches/ DARCS repository]

To set up can interface, it is necessary to configure the communication speed first and then bring the interface up. Communication speed can be set up using following command (for can0 interface):

echo 660000 >/sys/class/net/can0/can_baudrate

The constant 660000 was found experimentally, driver seems to calculate the transmission speed improperly. To bring up the can network interface, use the same command as with any other network interface, i.e.

ifconfig can0 up

The most comfortable way of setting up both can interfaces upon startup of system is to place following script to /etc/init.d/ (name it 'can', for example)

echo 660000 >/sys/class/net/can0/can_baudrate
echo 660000 >/sys/class/net/can1/can_baudrate
ifconfig can0 up
ifconfig can1 up

==CanFestival==

===Obtaining and building CanFestival===

CanFestival driver source can be downloaded from. The primary way how to do it is to check out the source directory from CanFestival CVS by these steps:
cvs -d:pserver:anonymous@lolitech.dyndns.org:/canfestival login
(type return, without entering a password)
The system will respond:
Logging in to :pserver:anonymous@lolitech.dyndns.org:2401/canfestival
Then, enter:
cvs -z3 -d:pserver:anonymous@lolitech.dyndns.org:/canfestival co -P CanFestival-3
Then insert CanFestival folder and run this commands:
./configure --timers=unix --can=socket --cc=powerpc-603e-linux-gnu-gcc --arch=ppc --os=linux --target=unix
make
make install
Building of CanFestival will produce some libraries and copy them to /usr/powerpc-603e-linux-gnu/lib folder.

===Setting up local CANopen node===

CanFestival source includes tool called ''objdictedit''. This program has graphical user interface and serves to creating configuration of the CANopen node of application we develop. It is started by command ''objdictedit''. Using this program you can create the object dictionary for the CanFestival. Mainly it is necessary to set up all SDO and PDO, the node has to send and receive. To each PDO you have to define more things - PDO receive or transmit, variable to be mapped and variable mapping. The variable will then be used in application code to exchange data between CanFestival driver and application. If you set up PDOs here they will be sent and received automatically and the values will be stored into mapped variable. Setting up SDO means that you can use it in your application, but if you want to send it, it has to be done in code.
After creating this basic configuration you have to build the dictionary which results into to files with extensions .h and .c. You have to link these files with your application.

===Initializing and starting CanFestival===

To explain how to use CanFestival I include some code examples. It supposes node configuration generated by ''objdictedit'' which name is ''canopen''. It is then used as prefix of automatically generated functions and variables (''canopen_Data'' is for example object dictionary used by CanFestival).
Header ''canfestival.h'' has to be included. For start using CanFestival it is necessary to load dynamic library with CAN bus driver API created while compiling CanFestival source. In the example SocketCan driver is used to access CAN bus.
if(!LoadCanDriver("libcanfestival_can_socket.so")) {
exit -1;
}
Then you have to open CAN device. Parameters of the communication have to be prepared in structure of type ''s_Board''. In this case CAN is set to use device ''can1'' and baudrate 1Mbps. Handler of the bus is then stored to variable of type ''CAN_HANDLE''.
/**
* CAN board definition.
* Device name can1, baudrate 1M
*/
s_BOARD canopen_board = {"1", "1000"};

CAN_HANDLE canopen_handle;

if(!(canopen_handle = canOpen(&canopen_board, &canopen_Data))) {
exit -1;
}
CanFestival implements callbacks to some events like change of state or message reception. There are pointers to callback functions in ''canopen_Data'' structure. You can assign your own functions to these pointers or leave them unused.
canopen_Data.initialisation = canopen_initialisation;
canopen_Data.preOperational = canopen_preOperational;
canopen_Data.operational = canopen_operational;
canopen_Data.post_sync = canopen_post_sync;
canopen_Data.post_TPDO = canopen_post_TPDO;
canopen_Data.stopped = canopen_stopped;
After setting up these few things you have to call function ''StartTimerLoop'' which initializes CanFestival timers. As an argument you have to insert pointer to the first function you want to proceed after starting the timers.
StartTimerLoop(&initNode);
Here is an example of such a function. It sets local node ID to 1 and bring the node to operation state. Callback functions are called after changing state if used.
void initNode(CO_Data * d, UNS32 id)
{
setNodeId(&canopen_Data, 0x01);
setState(&canopen_Data, Initialisation);
setState(&canopen_Data, Operational);
}

===Stopping CanFestival===

After finishing work with CANopen it is good to stop the communication and timers and close the device. It is done by these few functions.
setState(&canopen_Data, Stopped);
StopTimerLoop();
canClose(&canopen_Data);
canopen_handle = NULL;

===Writing to Object dictionary===

CANopen devices and all network services of each node are configured by writing to device object dictionary (OD). It is different while writing to local OD or OD of some network device.
====Writing to local OD====
Function ''WriteLocalDict'' is used for writing to OD of local node managed by CanFestival.
UNS32 writeLocalDict( CO_Data* d,
UNS16 wIndex,
UNS8 bSubindex,
void * pSourceData,
UNS8 * pExpectedSize,
UNS8 checkAccess);
Meaning of function arguments:
'''d''' - pointer to local object dictionary structure
'''wIndex''' - the index in the object dictionary where you want to write an entry
'''bSubindex''' - the subindex of the Index. e.g. mostly subindex 0 is used to tell you how many valid entries you can find in this index. Look at the canopen standard for further information
'''pbSourceData''' - pointer to the variable that holds the value that should be copied into the object dictionary
'''pExpectedSize''' - pointer to variable with size of the data to be written
'''CheckAccess''' - if other than 0, do not read if the data is Read Only or Constant

====Writing to network OD====

It is necessary to use SDO service for writing data to OD of some network device. Each CANopen device has at least one SDO server. It means that it is able to receive SDOs with one ID and answer by SDOs with another ID. It is usual that the server listen for SDOs with ID 0x600 + ID of the node and transmits SDOs of ID 0x580 + node ID. Each SDO we want to use has to be defined while creating node configuration by ''objdictedit''. Then the SDO is sent by calling appropriate function. The best is to use function ''writeNetworkDictCallBack'' which syntax is shown below.
UNS8 writeNetworkDictCallBack (CO_Data* d,
UNS8 nodeId,
UNS16 index,
UNS8 subIndex,
UNS8 count,
UNS8 dataType,
void *data,
SDOCallback_t Callback);
Meaning of function arguments:
'''d''' - pointer to local object dictionary structure
'''nodeId''' - ID of the device we want to send SDO
'''index''' - the index in the object dictionary where you want to write an entry
'''subIndex''' - the subindex of the Index. e.g. mostly subindex 0 is used to tell you how many valid entries you can find in this index. Look at the canopen standard for further information
'''count''' - number of bytes to be written
'''dataType''' - type of the data, use 0 for integers, real numbers and other values
'''data''' - pointer to the data
'''Callback''' - pointer to a function which is called after finishing the transfer
The SDO service is by definition confirmed. It means that SDO server sends response with result of the transfer after each SDO reception. This response has to be read by client to be sure that the data were written correctly. The result should be read in your function which pointer is given to the function ''writeNetworkDictCallBack'' as parameter ''callback''. The result of SDO transfer in such a function is read by CanFestival function ''getWriteResultNetworkDict''. This function has to be called after each SDO transmission because it releases line used to transfer. Header of this function is:
UNS8 getWriteResultNetworkDict (CO_Data* d, UNS8 nodeId, UNS32 * abortCode);
And meaning of function arguments is:
'''d''' - pointer to local object dictionary structure
'''nodeId''' - ID of the device we have sent SDO
'''abortCode''' - pointer to the variable where error code is written in case of error
The function can return one of these values according to the SDO transfer state:
'''SDO_FINISHED''' - data is available
'''SDO_ABORTED_RCV''' - Transfer failed. (abort SDO received)
'''SDO_ABORTED_INTERNAL''' - Transfer failed. Internal abort.
'''SDO_DOWNLOAD_IN_PROGRESS''' - Data not yet available
The function can be used in cycle waiting while return value is ''SDO_DOWNLOAD_IN_PROGRESS''. But the better solution is calling it in callback function from ''writeNetworkDictCallBack''. The callback is call after finishing the transfer.

===Using PDO service===

Using PDO service for data exchange is very easy in CanFestival. The most usual transmission type of PDOs is that they are transmitted after SYNC message. In this case it just has to be set up in objdictedit configuration and then it works, reads and stores values into mapped variables. After each PDO reception or transmission ''post_TPDO'' callback is called if used.
Sometimes it is necessary to send PDO from code without SYNC message reception. This is very inconsistent in CanFestival version 3. There are some functions which should solve this situation but they are commented and some other solution is promised to be done in the future. For now I have done it by using function sendPDO which syntax is:
UNS8 sendPDO (CO_Data* d, s_PDO pdo, UNS8 request);
And meaning of function arguments is:
'''d''' - pointer to local object dictionary structure
'''pdo''' - structure with PDO message
'''request''' - REQUEST (request for sending PDO) or NOT_A_REQUEST (normal PDO)
PDO message has to be created using structure s_PDO which meaning is clear:
typedef struct struct_s_PDO {
UNS32 cobId; /* COB-ID */
UNS8 len; /* Number of data transmitted (in data[]) */
UNS8 data[8]; /* Contain the data */
} s_PDO;

===Generating SYNC message===

If you want to set up local node to become the SYNC server you have to write some information to local OD. Here is an example of function which set up the SYNC messages generation:
/**
* This function initializes local canopen node to send SYNC message
* with given period.
* @param d - local object dictionary
* @param period - period of the SYNC message in us
*/
void synchro_setup(CO_Data *d, unsigned long period)
{
UNS32 SYNC_COBID = 0x40000080;
UNS32 SYNC_INTER = period;
UNS8 size = sizeof(UNS32);
writeLocalDict(d, 0x1006, 0x0, &SYNC_INTER, &size, RW);
writeLocalDict(d, 0x1005, 0x0, &SYNC_COBID, &size, RW);
}
According to CANopen specification ID of the SYNC message is 0x80.
After the setup it can be started by command ''startSYNC(CO_Data *d)'' and stopped by command ''stopSYNC(CO_Data *d)''.

===SDO and PDO example===

At the end I attach example of a function (''cpd_start()'') which starts some device communicating by CANopen. The ID of the device is given by the parameter. The other function (''cpd_checkSDO_start()'') is callback used to handle SDO transfer result. It is necessary to wait until one SDO transfer is finished before starting some other. Global variable ''cpd_init_step'' is used for counting actual step of SDO transfer. If some SDO transfer fails it is set to -1 and the startup process is terminated.
/**
* This function is given to the writeNetworkDict function as a callback.
* It checks the result of SDO transmition and after finishing the transmition
* it closes the transfer.
* @param d - local object disctionary
* @param nodeID - ID of the node which the local node is communicating with
*/
void cpd_checkSDO_start(CO_Data* d, UNS8 nodeId)
{
UNS32 abortCode;
if(getWriteResultNetworkDict (d, nodeId, &abortCode) != SDO_FINISHED) {
cpd_init_step = -1;
}
closeSDOtransfer(&canopen_Data, nodeId, SDO_CLIENT);
cpd_start(&canopen_Data, nodeId);
}

/**
* This function switch canopen device into operational state.
* @param d - local object dictionary
* @param nodeId - ID of the device
* return 0 - ok, -1 - failed
*/
int cpd_start(CO_Data *d, UNS8 nodeId)
{
UNS8 data8;
UNS16 data16;
UNS32 data32;
switch(cpd_init_step++) {
case 0:
masterSendNMTstateChange(d, nodeId, NMT_Start_Node);
s_PDO pdo;
cpd_controlword = 0;
pdo.cobId = 0x200 + nodeId;
int i = 0;
for(i = 0; i < 8; i++) {
pdo.data[i] = 0;
}
pdo.data[0] = 0;
pdo.data[1] = 0;
pdo.len = sizeof(pdo.data);
sendPDO(d, pdo, NOT_A_REQUEST);
cpd_controlword = 6;
pdo.cobId = 0x200 + nodeId;
for(i = 0; i < 8; i++) {
pdo.data[i] = 0;
}
pdo.data[0] = 7;
pdo.data[1] = 0;
pdo.len = sizeof(pdo.data);
sendPDO(d, pdo, NOT_A_REQUEST);
cpd_controlword = 0x0F;
pdo.cobId = 0x200 + nodeId;
for(i = 0; i < 8; i++) {
pdo.data[i] = 0;
}
pdo.data[0] = 0xF;
pdo.data[1] = 0;
pdo.len = sizeof(pdo.data);
sendPDO(d, pdo, NOT_A_REQUEST);

// Start operational mode
data8 = 0xFC;
writeNetworkDictCallBack(d, nodeId, 0x6060, 0x00, 1, 0, &data8, cpd_checkSDO_start);
break;
case 1:
// Check operation status
readNetworkDictCallback(d, nodeId, 0x6061, 0x00, 0, cpd_checkSDO_start);
break;
case 2:
// Setpoint specification
data16 = 0x0002;
writeNetworkDictCallBack(d, nodeId, 0x301B, 0x11, 2, 0, &data16, cpd_checkSDO_start);
break;
case 3:
canopen_init_result = 0;
cpd_init_step = 0;
break;
case -1:
canopen_init_result = -1;
cpd_init_step = 0;
break;
}
return 0;
}

===Emergency message===

CanFestival version 3 does not support reception of emergency messages. I have worked it around by adding callback into CanFestival source just into function reading data from CAN bus. Function ''canReceive_driver'' is placed in file ''<canfestival_directory>/drivers/can_socket/can_socket.c'' (for SocketCan driver only!). I have created pointer to a function which is set by application.
void (* emcy_callback)(Message *);
This code filters messages being received and all messages which ID agrees with EMCY service (0x80; 0x180) are sent to application function set as callback.
if(m->cob_id.w >= 0x81 && m->cob_id.w < 0x180) (*emcy_callback)(m);