AM2432: EtherCAT Slave connecting to KEYENCE KV7500 not successful

Here is the network packages captured for case 2, where analyzer is put between KV7500 and AM2432. The packages are as if there is only one drive connected. 

Nothing can be captured between 2 drives.

KV7500_CD3E_Inovance_fail.zip

Hi Jianyu,

Jianyu Wang said:

3. If KV7500 is connected to XMC4800, then AM2432, AM2432 would not return any frame on first connection.

• So in the first connection, no return frame is observed and the second time the PLC tries to establish a communication, the AM243x returns the frame as expected? Or is a power cycle mandatory at all times in Case 3?

For Case 2, can you provide the value in MDIO_LINK_REG register (0x300B240C) when a device is connected to port1 of AM243x and when no device is connected to port1 of AM243x. This is to check whether the corresponding PHY has established the link (when XMC4800). 

I'll review the logs and check for more details.

Regards,
Aaron

Also share PHY register dumps (0x0 to 0x1F) from Port connected to XMC4800

Hi, we have found another issue, so this test link is 1 PLC connect to 2 AM2432.

If the cable is disconnected, the link/act led is OFF for the first drive's out port. However, when I check the ESC register 0x110 DLstatus, it shows the out port is still connected, which would cause the first drive to no longer return the frames sent by the PLC.

I am not sure why our drive cannot detect the disconnection. The PHY out port design is attached. 

Do you guys have any suggestion? I'll probe the ecat_out_link signal today. I assume this signal is correct since the link/act LED responds to this signal.

Thanks,

Jianyu

LED1 is configured to which mode ?  It has to be a stable LINK (LED_SPEED or LED_LINK (without activity blink) )

Check the polarity of Link, this also needs to be configured via API accordingly.

LED_LINK, high active. We have rebuilt an EtherCAT slave based on SDK, the DLstatus is correct. Any more suggestion on checking the project which fails?

Hi Jianyu,

Please share the PHY register values (0x0 to 0x1F) from Port connected to XMC4800 as mentioned earlier in Case2.

Also, can you share the value in ESC Reg.0x0101 (0x30090101 in AM243x) and ESC Registers 0x30090300 to 0x30090313.This is to see how the MainDevice is configuring the SubDevice and also to see if any invalid frames are observed, respectively.

Details of these registers can be found here: ETHERCAT SUBDEVICE CONTROLLER REGISTER LIST

Regards,
Aaron

Hi Aaron,

Currently I am focusing on  1 PLC connect to 2 AM2432 issue. And we have tested another EtherCAT slave based on SDK(no 402 or other functions), it is working with KEYENCE KV7500 - AM2432 - XMC4800. So I assume the issue is in the project, not sure about the reason though.

Aaron Thomas said:

Also, can you share the value in ESC Reg.0x0101 (0x30090101 in AM243x) and ESC Registers 0x30090300 to 0x30090313.This is to see how the MainDevice is configuring the SubDevice and also to see if any invalid frames are observed, respectively.

Details of these registers can be found here: ETHERCAT SUBDEVICE CONTROLLER REGISTER LIST

OK, I'll update if I found anything.

Hi Jianyu,

Jianyu Wang said:

Currently I am focusing on  1 PLC connect to 2 AM2432 issue. And we have tested another EtherCAT slave based on SDK(no 402 or other functions), it is working with KEYENCE KV7500 - AM2432 - XMC4800. So I assume the issue is in the project, not sure about the reason though.

• Okay so earlier, you were seeing issue where the AM243x drive was not forward the frames to XMC4800 but after removing CiA402 or other functions/profiles, the issue is not observed, right? May I know which EtherCAT demo and SDK are you referring for your product?

Jianyu Wang said:

OK, I'll update if I found anything.

• Sure, thanks.

Regards,
Aaron

Aaron Thomas said:

Okay so earlier, you were seeing issue where the AM243x drive was not forward the frames to XMC4800 but after removing CiA402 or other functions/profiles, the issue is not observed, right? May I know which EtherCAT demo and SDK are you referring for your product?

The demo is based on ind_comms_sdk_am243x_09_01_00_03

Aaron Thomas said:

Also, can you share the value in ESC Reg.0x0101 (0x30090101 in AM243x) and ESC Registers 0x30090300 to 0x30090313.This is to see how the MainDevice is configuring the SubDevice and also to see if any invalid frames are observed, respectively.

Hi

We did following test:

1. We changed configuration of pin T2 (net ECAT_IN_LINK) to GPIO1_8 (per table below), initial muxmode is 1.
2. We see link indication (plug/unplug cable ) if we read it via  GPIO_IN_DATA (address 0x00601020) in bit 8.

a) Can you confirm that T2 (PRG0_PRU0_GPI8) is used by PRU for link indication detection?

b) is there some condition in PRU that can mask link indication on pin T2?

Thanks

Rasty

Hi Rasty, Jianyu,

Rasty Slutsker said:

a) Can you confirm that T2 (PRG0_PRU0_GPI8) is used by PRU for link indication detection?

• PRG1_PRU0_GPO8 and PRG1_PRU1_GPO8 corresponds to MII0_RXLINK and MII1_RXLINK respectively. These pins are required for enabling Enhanced Link. Can you confirm if this feature is enabled in your application? If yes, then can you make sure the link polarity is configured correctly? I'm referring to the following configurations in tiescsoc.c file: (Steps to configure the polarity is mentioned in the above document)

• #define TIESC_LINK0_POL                         TIESC_LINK_POL_ACTIVE_HIGH
  #define TIESC_LINK1_POL                         TIESC_LINK_POL_ACTIVE_HIGH
      
      
      bspInitParams->enhancedlink_enable = TIESC_MDIO_RX_LINK_ENABLE;
      bspInitParams->link0_polarity = TIESC_LINK0_POL;
      bspInitParams->link1_polarity = TIESC_LINK1_POL;

Also, please provide the PHY register values (0x0 to 0x1F) to understand the PHY configurations.

Regards,
Aaron

Hi

I confirm that 

1. We tried TIESC_MDIO_RX_LINK_ENABLE, the same results

2. TIESC_LINK0_POL and TIESC_LINK1_POL are High

3. Link signal is verified with scope (active High)

4. Link signal can be read from at pin T2 if pin is configured as regular GPIO

5. Most important we use PRG0, not PRG1 PRG0_PRU0_GPI8 and PRG0_PRU1_GPI8

6. Why do you mention PRG1_PRU1_GPO8 , it should be input, not output?

PHY configuration is less relevant (IMHO), since behavior of Link signal (connected to LED1) is confirmed digital scope.

Other ideas ?

Thanks

Rasty

Hi Rasty,

Rasty Slutsker said:

5. Most important we use PRG0, not PRG1 PRG0_PRU0_GPI8 and PRG0_PRU1_GPI8

• Thank you for this information. Looks like there's a misconfiguration in our application for EtherCAT on ICSSG0 Demo when MDIO Manual Mode is enabled. Can you confirm if it is enabled in your application? 
• 
• If this is enabled, you will have to update the following lines of code in tiesc_mdioManualModeSetup() present in tiescsoc.c file:

•     /* Pass value to R10 of TX_PRU core for MDIO FW WA Configuration */
      CSL_REG32_WR(CSL_PRU_ICSSG1_DRAM0_SLV_RAM_BASE + CSL_ICSS_G_PR1_PDSP_TX0_IRAM_DEBUG_REGS_BASE + PRU_REG_10, MDIO_MANUAL_MODE_FW_CONFIG_VALUE);
      /* Pass value to R12 of TX_PRU core for emulated MDIO Base Address */
      CSL_REG32_WR(CSL_PRU_ICSSG1_DRAM0_SLV_RAM_BASE + CSL_ICSS_G_PR1_PDSP_TX0_IRAM_DEBUG_REGS_BASE + PRU_REG_12, MDIO_MANUAL_MODE_BASE_ADDRESS);
      
      should be changed to
      
      /* Pass value to R10 of TX_PRU core for MDIO FW WA Configuration */
      CSL_REG32_WR(CSL_PRU_ICSSG0_DRAM0_SLV_RAM_BASE + CSL_ICSS_G_PR1_PDSP_TX0_IRAM_DEBUG_REGS_BASE + PRU_REG_10, MDIO_MANUAL_MODE_FW_CONFIG_VALUE);
      /* Pass value to R12 of TX_PRU core for emulated MDIO Base Address */
      CSL_REG32_WR(CSL_PRU_ICSSG0_DRAM0_SLV_RAM_BASE + CSL_ICSS_G_PR1_PDSP_TX0_IRAM_DEBUG_REGS_BASE + PRU_REG_12, MDIO_MANUAL_MODE_BASE_ADDRESS);

Hi

I don't see where MDIO_MANUAL_MODE_ENABLED.

We globally replaced CSL_PRU_ICSSG1 with CSL_PRU_ICSSG0 in all the places, assuming that no other adaptation required if we move Ethercat from ICSSG1 to ICSSG1, plus adjustment of PRU events, plus sysconfig.

It worked 99% except link indication.

Thanks

rasty

#ifdef MDIO_MANUAL_MODE_ENABLED
void tiesc_mdioManualModeSetup()
{
int32_t status;
/* ----------------------------------------------------------------- */
/* Load the MDIO firmware binary on PRU Core; */
/* ----------------------------------------------------------------- */
/* Reset Core */
status = PRUICSS_resetCore(pruIcss1Handle, PRUICSS_PRUx);
DebugP_assert(SystemP_SUCCESS == status);
/* Disabe Core */
status = PRUICSS_disableCore(pruIcss1Handle, PRUICSS_PRUx);
DebugP_assert(SystemP_SUCCESS == status);

/* Load firmware. Set buffer = write to PRU memory */
status = PRUICSS_writeMemory(pruIcss1Handle, PRUICSS_IRAM_TX_PRU(0), 0,
(uint32_t *) PRUFirmware, sizeof(PRUFirmware));
DebugP_assert(status != 0);

/* Pass value to R10 of TX_PRU core for MDIO FW WA Configuration */
CSL_REG32_WR(CSL_PRU_ICSSG0_DRAM0_SLV_RAM_BASE + CSL_ICSS_G_PR1_PDSP_TX0_IRAM_DEBUG_REGS_BASE + PRU_REG_10, MDIO_MANUAL_MODE_FW_CONFIG_VALUE);
/* Pass value to R12 of TX_PRU core for emulated MDIO Base Address */
CSL_REG32_WR(CSL_PRU_ICSSG0_DRAM0_SLV_RAM_BASE + CSL_ICSS_G_PR1_PDSP_TX0_IRAM_DEBUG_REGS_BASE + PRU_REG_12, MDIO_MANUAL_MODE_BASE_ADDRESS);

/* Run firmware */
status = PRUICSS_enableCore(pruIcss1Handle, PRUICSS_PRUx);
DebugP_assert(SystemP_SUCCESS == status);
}
#endif

Hi Rasty,

Rasty Slutsker said:

I don't see where MDIO_MANUAL_MODE_ENABLED.

• MDIO_MANUAL_MODE_ENABLED is defined when the check-box is chosen in EtherCAT sysconfig.

Rasty Slutsker said:

We globally replaced CSL_PRU_ICSSG1 with CSL_PRU_ICSSG0 in all the places, assuming that no other adaptation required if we move Ethercat from ICSSG1 to ICSSG1, plus adjustment of PRU events, plus sysconfig.

• I believe the reset sequence is taken care for the custom board used to utilize the PRU_ICSSG0 instance of the ICSSG peripheral.

Rasty Slutsker said:

It worked 99% except link indication.

• To clarify the current status, you still see the same issue after making the above changes?

Regards,
Aaron

Hi

I undertand that checkbox  (and function tiesc_mdioManualModeSetup) is related to "i2329 MDIO: MDIO interface corruption (CPSW and PRU-ICSS)" and loads additional firmware to PRU.

It is pretty unexpected. I had an impression that Link status is directly sampled by PRU via GPIO(8). Because pin function is set to (1, direct input to Local IO PRU). This pin has no other documented function.

We'll give a try.

Thanks

rasty

Hi Rasty,

Rasty Slutsker said:

We'll give a try.

• Do you have any update here?

Regards,
Aaron

Hi Aaron,

We check it now.

Meanwhile another question.

We tested behavior of registers R30/R31 of PRU with debugger.

According to my understanding,  R30 shall reflect state PRU local Inputs. Pin is configured to PRU_IN8

I do not see change in value of R30 when we change link state (we tested it on our board and also on EVB).

In both cases no correlation.

What do I miss?

Thanks

Rasty

Hi AAron

We tested your suggestion, it did not help. register 0x110 does not reflect change in link. Signals are confirmed with scope.

Other thoughts?

Thanks

Rasty

Hi Rasty,

Could you provide the ICSS Memory dump. I'm referring to the following sections:

• PRU_ICSSG_RAM: 0x30010000 - 0x30010ECF
• PRU_MII_RT_MII_RT: 0x30032000 to 0x3003206C
• PRU_MDIO_MDIO: 0x30032400 to 0x30032484

Regards,
Aaron

ECMemoryDump20_3.zip

Memory dumps

Hi Rasty,

The file type looks to be wrong and hence I can't view the values. If you're using CCS, could you provide the dumps in .dat format or any other readable format? You can follow these steps in CCS:

• Choose TI Data as File Type in View -> Memory Browser -> Save Memory: 
  •  
• Followed by choosing System_View as Memory Page in the next window:
  • 

 Regards,
Aaron

It is saved in raw binary format  you can open it with  any hex viwer. 

Hi Aaron,

I'd like to understand why link indication that is connected to PRU, while pin's function is set to PRU local digital input is not reflected in R30?

We checked it on our card and on evaluation board, in both cases it is not reflected in PRU as I expect.

What do I miss?

Thanks

Rasty

Rasty Slutsker said:

According to my understanding,  R30 shall reflect state PRU local Inputs. Pin is configured to PRU_IN8

This depends on the ICSS internal mux mode in ICSSG_GPCFG0/1_REG registers - EtherCAT uses MII  vs GP

Rasty Slutsker said:

ECMemoryDump20_3.zip

Memory dumps

This looks to be taken once board is powered up, can you share the dumps when the issue occurs. You can share the full ICSSG0 address space - 0x3000_0000 to 0x3003_4000

Will be also good to check this setup with MDIO_MANUAL_MODE_ENABLED and enhanced link detection disabled since you are suspecting that PHY LED_LINK is not reaching ICSS.

Hi

I'm sharing the memory dump on Rasty's behalf.

i couldn't choose the "system_view" Memory page (probably running an older version).PRU_ICSSG_RAM_0x30000000_0x30034000.dat

PratheeshGangadhar I'm absolutely firm that Link signal is produced by PHY and arrives to the right pin. Please read my older messages in this thread.

Hi Rasty,

From the logs you provided, looks like MDIO Manual Mode is enabled (0x0E35.bit0 is set) and Enhanced Link detection is disabled (0x0E36.bit0 is 0). In your application sysconfig, make sure MDIO Manual Mode Link Status Update is set to PHY Polling Based:

This is required if MDIO Manual Mode is enabled and Enhanced Link is disabled. Can you confirm if this configuration is done in your side? If not, can you try with this and update us of the status?

Regards,
Aaron

Hi

We tried all combinations - does not work.

I remind that link indication arrives from dedicated pin in PHY and checked with scope.

What I do not understand is why in manual mode it is still PRUICSS_GPI_MODE_MII_RT.

PRUICSS_setGpiMode(pruIcss0Handle, PRUICSS_PRU0, PRUICSS_GPI_MODE_MII_RT);
PRUICSS_setGpiMode(pruIcss0Handle, PRUICSS_PRU1, PRUICSS_GPI_MODE_MII_RT);

I expect that in manual mode, pins are directly controlled by PRU via R30 and R31.

Thanks

Rasty

@TI team 

Thank you very much for the help.

I'd like to contribute to troubleshooting.

Link indication comes from PHY pin and cannot be fully checked withTwinCAT, because you would need to disconnect EtherCAT cable to check status of register 0x110.

Even without proper link indication Ethercat may work "normally". System can reach OP even without link indication. Missing or inverted link indication can be unnoticed for a long time.

If we talk about ICSS0, register 0x110 can be read from memory location 0x30010110 with debugger.

Actual state of link pin may be seen in register R31 of PRU (bit 8), if PRU0_GPI_MODE/PRU1_GPI_MODE  is set manually to 0.