AM6421: Ethernet/IP Class 1 connection gets interrupted by Class 3 connection

Hi Kai,

Thanks for reaching out.

Please expect a slight delay in the response, since our expert is currently out-of-office.

Regards
Archit Dev

ok, looking forward for an answer

Hello Archit Dev,

I did some more research and added prints in out R5 code.

15752: EtherNetIP_CipCallbacks_u8CustomServiceStackCb (enter):: classId 0x0083, instanceId 1, attrId 1, service 0x4B
15879: EtherNetIP_CipCallbacks_u8CustomServiceStackCb (exit):: instanceId 1, data length 4, custServiceResult 1
15887: EtherNetIP_CipCallbacks_u8CustomServiceStackCb (enter):: classId 0x0083, instanceId 2, attrId 1, service 0x4B
16020: EtherNetIP_CipCallbacks_u8CustomServiceStackCb (exit):: instanceId 2, data length 4, custServiceResult 1
16028: EtherNetIP_CipCallbacks_u8CustomServiceStackCb (enter):: classId 0x0083, instanceId 1, attrId 1, service 0x4B
16156: EtherNetIP_CipCallbacks_u8CustomServiceStackCb (exit):: instanceId 1, data length 4, custServiceResult 1
16980: EtherNetIP_CipCallbacks_u8CustomServiceStackCb (enter):: classId 0x0083, instanceId 1, attrId 1, service 0x4B
17110: EtherNetIP_CipCallbacks_u8CustomServiceStackCb (exit):: instanceId 1, data length 4, custServiceResult 1
17117: EtherNetIP_CipCallbacks_u8CustomServiceStackCb (enter):: classId 0x0083, instanceId 2, attrId 1, service 0x4B
17246: EtherNetIP_CipCallbacks_u8CustomServiceStackCb (exit):: instanceId 2, data length 4, custServiceResult 1

Looking at these it seems that the stack does not handle requests in parallel. Therefore the application cannot be responsible for the blocking and this is something that need to be handled in the stack.

Hello Kai,

what is the task priority for Cyclic IO in your application? Per default both the "Packet" task (which is mainly responsible for Class 3 messages) and Cyclic/IO Task have the same priority, can you change the priority of Cyclic/IO task to a higher priority and check if it resolves the Problem?

Best regards,
Pourya

Hello Pourya, 

Task priority of cyclic io and packet task was both on Prio 20. I tested also a higher priority for the cyclic IO task but that hasn't solved the blocking issue.

In our device we request the data from the A53 core so it takes some time until the custom service callback returns. Is this also taken into account when handling class 3 connections in the stack?

Best regards,

Kai

Hello Kai,

I need a bit more context here, what is the procedure you use to collect the data for Class 3 connection from the A53 core?
Is there at some point interrupts disabled? From logical stand point, even if the "Packet" task is blocked for some time, the Cyclic/IO Task should not be affected, unless the scheduler is disrupted in someway.

Is there also some async layer involved for consuming/producing I/O data from another core? are there any blocking functions involved?

Best regards
Pourya

Hello Pourya, 

sure. Here are some insights:

Out application is running on the Linux core, we have two rpmsg channels, one for cyclic and one for acyclic data. The cyclic data is exchanged with the assembly using EI_API_CIP_setAssemblyData and EI_API_CIP_getAssemblyData without blocking.

The acyclic callback sends the data in a message to the linux core and waits for the corresponding response. Here of course we are blocking in the callback but afaik interrupts are not disabled. At least not for the whole time. I can check this again.

BR

Kai

I checked again with adding a sleep and returning without rpmsg communication. The result is the same. Cyclic communication is blocked. Are you able to reproduce this behaviour on your evm board`in a eip sample project?

  /* Setup response data. */
  ptProduceBuf_p->pDataBuf[0] = 0x80 + serviceCode_p; // Reply service code
  ptProduceBuf_p->pDataBuf[1] = 0u;                   // Reserved (always zero)
  ptProduceBuf_p->pDataBuf[2] = 0u;                   // General status code
  ptProduceBuf_p->pDataBuf[3] = 0u;                   // Size of Additional/Extended Status
  ptProduceBuf_p->actData = CIP_RESPONSE_HEADER_SIZE;

  ptProduceBuf_p->actData += 8;
  ptProduceBuf_p->pDataBuf[4] = 'T';
  ptProduceBuf_p->pDataBuf[5] = 'E';
  ptProduceBuf_p->pDataBuf[6] = 'S';
  ptProduceBuf_p->pDataBuf[7] = 'T';
  ptProduceBuf_p->pDataBuf[8] = 'T';
  ptProduceBuf_p->pDataBuf[9] = 'E';
  ptProduceBuf_p->pDataBuf[10] = 'S';
  ptProduceBuf_p->pDataBuf[11] = 'T';

  OSAL_SCHED_sleep(100);

  return EI_API_CIP_SERVICE_eERR_ERR_RESPONSE;

Hello Kai,

I could reproduce this behavior by introducing an artificial delay in a get_attribute callback, allow me sometime to investigate this issue further, I'll inform you when I find a solution.

Best regards,
Pourya

Thanks for the update

Hello Pourya:

 will that fix be rolled into the version 10.1 of the Industrial Comms SDK?

Hello Pourya,

I applied the patch you sent to ind comms sdk 9.2.0.15 and tested but I got errors during startup:

9303: EtherNetIP_Stack_pruLoad (exit)::
9304: EtherNetIP_CipCallbacks_vSetConnectionList (enter)::
9310: EtherNetIP_CipCallbacks_vSetConnectionList (exit)::
9315: EtherNetIP_Connection_setAssemblyList (enter)::
9320: EtherNetIP_Connection_setAssemblyList (exit)::
9325: EtherNetIP_Stack_pruStart (enter)::
9330: EtherNetIP_Stack_pruStart:: Starting PRU
9334: EtherNetIP_Stack_pruStart (exit)::
9338: EtherNetIP_CipCallbacks_configure (enter)::
9343: ERROR: EtherNetIP_CipCallbacks_configure (EtherNetIP_CipCallbacks.c: 556):: EI_API_CIP_setInstanceServiceFunc; Err: 0x38020402
9355: ERROR: EtherNetIP_Stack_vMainTask (EtherNetIP_StackConfigure.c: 858):: Configure callbacks Error: 0x38020402
9366: EtherNetIP_Configuration_u32MarkComplete (exit):: result 0x38020402
9376: EtherNetIP_Configuration_u32Finalize (enter)::
9378: EtherNetIP_Stack_vMainTask:: finalize interrupt recv
9384: Boot mode is DHCP

9387: LLDP Data Table Object should support at least 8 instances.

9392: kbEI_LLDP_datatable_init: 0x80000000 EC is fatal=1, SRC:kbEI_LLDP_datatable_init:64

9400: ERROR: EtherNetIP_CipCallbacks_vOsErrorHandlerCb (EtherNetIP_CipCallbacks.c: 1036)::
###### OS Error: 0x80000000, fatal: TRUE ######

9413: EtherNetIP_Acyclic_Glue_vStackErrorIndicatedCallback (enter):: errorCode 0x80000000, fatal TRUE
9422: EtherNetIP_Acyclic_Glue_vStackErrorIndicatedCallback (exit)::
10378: EtherNetIP_Configuration_u32Finalize (exit):: result 0xFFFFFFFE

Can you please have a look on the log? Is the patch maybe based on a newer sdk?

Regards

Kai