[etherlab-users] [etherlab users] Kernel Panic in EoE context

[Erwin Burgstaller]

Hi!

Now we got a stable running solution with the EtherCAT master having EoE
enabled and in conjunction with a RTAI task.

We mainly modified the request-lock callback function to work like this:

static int requestLock(void *)
{
   if (rtf_sem_trywait(masterLock_m) < 1)
   {
      return -1;
   }

   return 0;
}

Doing it this way, the masters routine is never blocked in some rtai code.

It seems to work only, with using RTAI's fifo based semaphores. So
masterLock_m has to be an integer associated with an open rtai fifo,
which has then been used with rtf_sem_init().

The release-lock call-back function looks like this:

static void releaseLock(void *)

   rtf_sem_post(masterLock_m);
}

In the rtai loop, there's also just a try to lock, but that's more for
having control and for debugging purpose, but basically it works like
this:

   while (runLoop_m)
   {
      timerLastCycle_m = rt_get_time();

      while (rtf_sem_trywait(masterLock_m) < 1)
      {
        rt_sleep(nano2count(10000)); 
      }
      
      // receive process data
      ecrt_master_receive(pMaster_m);
      ecrt_domain_process(pDomain0_m);


Be aware of using rt_sleep() with a to short value. It will lock the
whole system, because the rtai scheduler will not put the process out
of the run queue and the eoe interrupt routine will never have a chance
to do it's work.

As I heard, the whole thing will change in version 1.5, so this is just
for the records, but maybe somehow helpful though.


Erwin

-- 
Erwin Burgstaller