[etherlab-users] Real-time issues in i.MX6Q using generic driver and Xenomai

[Raimarius Delgado]

Hello everyone,
I've tried to port IgH EtherCAT Master 1.5.2 to i.MX6Q SABRELite bought 
from boundary devices using dual-kernel approach for real-time Linux 
based on Xenomai. Since there is no available native driver for FEC 
(network device on i.MX6Q board), generic driver is my final resort. 
However, I'm experiencing real-time issues where the EtherCAT task 
execution time is showing higher values than the configured period of 
the cyclic task (e.g., >1ms for 1ms cyclic task) which violate hard 
real-time constraint. Inside the task, only a single call to 
EC_WRITE_U32 was made to write a constant value to be sent to the slave.

The timing results are obtained using rt_timer_read(), which is a timing 
probe provided by Xenomai Native API. The EtherCAT realtime task is 
shown in the pseudo code below:

void Control_Task(void *cookie){
end = rt_timer_read();
while(1)
{
     wait_period(NULL) ; //wait for the next periodic release point
     start = rt_timer read; /* Task period start*/

     /* receive process domain */
     ecrt_master_receive(master);
     ecrt_domain_process(domain);

     check_master_state();
     check_slave_state();
     check_domain_state();

     EC_WRITE_U32(domain_pd + targetveloffset, 1000);

     ecrt_master_application_time(master,master_app_time);
         if(sync){
             sync--;
         }else{
             sync++;
             ecrt_master_sync_reference_clock(master);
         }

     /* send process domain*/
     ecrt_domain_queue(domain);
     ecrt_master_send(master);

     ecat_lat=rt_timer_read();  /* EtherCAT execution time end */

     period = start - end;
     execution_time =  ecat_lat - start;
     end = start; /* Task period end*/
}

In a Xenomai user space task configured to a cycle time of 1 ms, the 
execution_time spikes to about 1.3 ms. Upon further analysis (adding 
rt_timer_read() at certain points within the task), high latency occurs 
during the call  to ecrt_master_receive and ecrt_domain_process.  Has 
anyone tried to solve this problem? To my knowledge,  the task is 
running in secondary mode because I am using the generic driver  so this 
is one cause of the high latency.  But running the same task to a 
different embedded board (BeagleBone Black) shows that the real-time 
constraints were met. I hope there is a different solution than 
developing an ec_device for FEC since that would take a long time (such 
as patch for imx6q to handle IRQ when using Xenomai, imx6q patch for 
FEC, or something alike).

The overall system architecture of my development environment is as follow:
Board - BD-SL-I.MX6 (i.MX6Q SABRELite) by Boundary Devices
Bootloader - U-boot 2015.07
Toolchain - gcc-linaro-arm-linux-gnueabihf-4.8-2014.04_linux
Linux Kernel - Linux 3.14.15 armv7 multiplatform 
(https://github.com/RobertCNelson/armv7-multiplatform.git)
Xenomai - Xenomai 2.6.4
ADEOS - ipipe-core-3.14.17-arm-2.patch
EtherCAT Master - IgH EtherCAT 1.5.2

Thank you in advance,
Raim

-- 
Raimarius Delgado, M.Sc.Eng. (레임)
Embedded Systems Laboratory
Seoul National University of Science and Technology
Dept. of Electrical and Information Engineering
Phone: +82-2-970-9868
Mobile: +82-10-2129-4987