• State Resolved
  • Locked Locked
  • Replies 7 replies
  • Subscribers 102 subscribers
  • Views 658 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

AMIC110: EtherNet/IP trouble

rei
Mastermind 6155 points
Part Number: AMIC110

Hello,

My customers have created the EtherNet/IP Adapter product using the AMIC110.
Master (Scanner) is connected to 7 Slaves (Adapter) in a daisy chain.


After running for several days, the Slave device will randomly enter an infinite loop and communication will not be possible.
The frequency is unknown. Sometimes it does not occur in a week, and sometimes it occurs in tens of hours.

They have verified in various environments, slave changes, cable changes....
As a result, we suspect that the AMIC110 software is the problem.
This program is almost the same as the PRU-ICSS EtherNet IP example.

・PROCESSOR-SDK-RTOS　(version: 05.02.00.10)
・PRU-ICSS-ETHERNETIP-ADAPTER　(version: 01.00.03.04)
・Code Composer Studio (version:9.3.0.00012)

When communication is lost, the device is in the infinite loop.

pdk_am335x_1_0_13\packages\ti\transport\ndk\nimu_icss\src\nimu_icssSwitchEmac.c
while in the "NIMU_ICSS_rxServiceCheck" function.

We are guessing there's probably a problem in ICSS_EmacRxPktGet called by rxCallBack.
pdk_am335x_1_0_13\packages\ti\drv\icss_emac\src\icss_emacDrv.c

The normal operation is "update_rd_ptr <queue_wr_ptr", and WP (wr_ptr) is copied to RP (rd_ptr).
When this problem occurs, update_rd_ptr (RP)> queue_wr_ptr (WP).
Therefore, "if (update_rd_ptr! = Queue_wr_ptr)" is always true and "rxArg-> more = 1" is performed.
Normally this does not happen. (Because of the ring buffer, it may happen occasionally)

Customers have the following questions:
Q1: When does "RP> WP" occur?
Q2: Could you tell me how to solve this situation.

Regards,

Rei

  • 0
    TI__Mastermind 26034 points

    Hi
    We have following questions to help us understand the issue better:
    1. In which slave is the issue seen?

    2. Is the issue reproducible with single slave?

    Regards
    Dhaval Khandla

  • 0 in reply to Dhaval Khandla
    Mastermind 6155 points

    Hi,

    Thank you for your reply.

    1. This happens on all slaves.

    2. I'm checking with the customers.

    Regards,

    Rei

  • 0 in reply to rei
    Mastermind 6155 points

    Hi,

    2. There is no problem with single slave. 

    When this issue occurs, the slave device cannot communicate, but it can communicate with the slave devices behind the daisy-chain.
    On the problem device, RTOS is working properly, and interrupts and high-priority tasks are working. That's why we suspect the ICSS_EmacRxPktGet func (task).

    Regards,

    Rei

  • 0 in reply to rei
    Mastermind 6155 points

    Hi,

    My customer investigated this issue further.
    ・ Reducing slave, reduces the frequency of issue.
    ・ It is likely to occur when ARP is sent from Slave to Master.
    ・ It occurs even if the PRU port is replaced.
    ・ Occurs when queue_rd_ptr (RP)> queue_wr_ptr (WP).

    They logged these and confirmed the issue.

    ICSS_EmacRxPktGet function
    ・ Queue_wr_ptr
    ・ Queue_rd_ptr
    ・ Rd_packet_length

    Send/Receive the following packets.
    ・EtherNet / IP packet 110 Bytes (DescriptorSize 16)
    ・ARP packet 60 Bytes (DescriptorSize 8)

    They prepared a ring buffer for debugging.

      if(emacMode == 0U) { /*Switch Mode*/
        temp_addr = ((((ICSS_EmacHwAttrs const *)icssEmacHandle->hwAttrs)->emacBaseAddrCfg)->dataRam1BaseAddr+ pStaticMMap->p0QueueDescOffset + (((uint32_t)(queueNumber))*8U));   
        qDesc = (ICSS_EmacQueue *)(temp_addr);
  } else {   
       temp_addr = ((((ICSS_EmacHwAttrs const *)icssEmacHandle->hwAttrs)->emacBaseAddrCfg)->sharedDataRamBaseAddr + hostQDescOffset + (((uint32_t)(queueNumber))*8U)); 
       qDesc =   (ICSS_EmacQueue *)(temp_addr); 
   } 
   queue_wr_ptr = qDesc->wr_ptr; 
   queue_rd_ptr = qDesc->rd_ptr;
/*DEBUG*/    
   wp_tbl[p_idx] = queue_wr_ptr; 
   rp_tbl[p_idx] = queue_rd_ptr;
/*DEBUG*/

      /* Take out the port number - it may have changed */    
   rxArg->port = (0x00030000U & rd_buf_desc)>>16; 

   temp_addr = (rd_buffer_l3_addr + 6U);
   srcMacId = (uint8_t*)(temp_addr);

    destMacId = (uint8_t*)rd_buffer_l3_addr;

    rd_packet_length = ((uint16_t)((0x1ffc0000U & rd_buf_desc) >> 18));

/*DEBUG*/  
   pk_len[p_idx] = rd_packet_length;   
   p_idx = (p_idx+1)&0x0f;
/*DEBUG*/

    They checked the log in the ring buffer.

    8306.e2e.pdf

    Normally, when rd_packet_length is 8, queue_wr_ptr is set to +8.
    However, case of issue, it becomes +16. Therefore, WP <RP occurs and WP! = URP continues. We think it is this problem that I cannot get out of loop.

    Could you give me any solution or advice?

    I’d like to ask you for your help. This happened just before the release, so we're in a hurry to resolve it. 

    Best regards,

    Rei

  • 0 in reply to Dhaval Khandla
    Mastermind 6155 points

    Hi Dhaval,

    Do you have any update on this issue?

  • 0 in reply to Dhaval Khandla
    Mastermind 6155 points

    Hi,

    I sent you a message. Have you received it?

    Regards,

    Rei

  • +1 in reply to rei
    TI__Mastermind 26034 points

    Closing this thread based on the discussion over email.