• State Resolved
  • Locked Locked
  • Replies 4 replies
  • Subscribers 97 subscribers
  • Views 828 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

EtherCAT slave communication problem

Denis Skvortsov
Prodigy 30 points
Other Parts Discussed in Thread: AM3359, TLK110

Hello,

We have created our own product based on AM3359 processor to provide high frequency signal acquisition over EtherCAT. We now have prototype hardware and are in the process of debugging it. Currently all the hardware is operational except for the EtherCAT communication.

Our board is very similar to the 3359ICE and has the same DDR, NOR flash, TLK110s.

Once connected to the EtherCAT network I can see packets going to the board (using Wireshark) but there are no replies. Also there are no callbacks been called from the PRUSS, but the LEDtask is driving the port activity light (flashing on/off at the same rate as the hardware activity LED connected to the PHY).

I have debugged our EtherCAT application on the 3359ICE dev board before moving it to our own hardware. I have also compared the contents of the TLK110 registers between our hardware and development board: for the registers 0x00 through to 0x1F the contents is identical (i.e. link up at 100MBit in full duplex mode). I have further tried looking at the PRUSS registers: PRUSS_CFG_BASE, PRUSS_IEP_BASE and PRUSS_MDIO_BASE but unable to see anything majorly differences.

I am not sure where to look next and any advice would be appreciated!

Regards,

Denis.

  • 0
    TI__Mastermind 47991 points

    Hi,

    Did you try both ports ?

    Is this board based on PG2.x or PG1.x ?

    > Make sure pinmux is configured correctly, for Eg:-  sdk\protocols\ethercat_slave\ecat_appl\EcatStack\ecat_appl_cnfg.h

    Depending board design PRU-ICSS internal pinmux need to be configured correctly. For ICE v1, LCD pins are muxed with Port0 MII RX pins 

            PRUSSPinMux_Config(0x01); // PRUSS pinmuxing

    { 0x08E0 , 6 , AM335X_PIN_INPUT }, // pr1_mii0_rxd_post[3] lcd_vsync
    { 0x08E4 , 6 , AM335X_PIN_INPUT }, // pr1_mii0_rxd_post[2] lcd_hsync
    { 0x08E8 , 6 , AM335X_PIN_INPUT }, // pr1_mii0_rxd_post[1] lcd_pclk
    { 0x08EC , 6 , AM335X_PIN_INPUT }, // pr1_mii0_rxd_post[0] lcd_ac_bias_en

    > What is the address of PHYs (ICE v1 configures this as 1 and 2 respectively) ? Modify TIESC_MDIO_PHY0/1_ADDR in tiescbsp.h to match your board.

    If this does not help, after sending the packet - read PRU INTC SRSR1 (0x4a320200) and SRSR2 ((0x4a320204) registers and report the values.


  • 0 in reply to PratheeshGangadhar
    Prodigy 30 points

    Thank you for your reply.

     

    I have tried both ports and on the second port I get activity LED (driven by the LEDTask) solidly on but again no callbacks.

    Enabling brakepoints in all ISRs I get about 5 calls to EscCmdLowAckIsr() just after system starts and that is it.

     

    The processor version is PG1.x.

     

    I have double checked the pinmux and it is the same as on ICEv1 (we have kept the conections to PHYs and their IDs are the same).  MUX_SEL_REG reads back as 0x1.

     

    SRSR1 register is 0x0 when board starts and 0x100 when cable plugged in and communication attempted (this matches the ICE board).

    SRSR2 is 0x0 going to 0x498 respectively (0x40C on ICE board).

  • 0 in reply to Denis Skvortsov
    TI__Mastermind 47991 points

    Hi,

    0x40C implies slave saw RX_SOF, RX_SFD and RX_EOF on Port0

    0x498 implies slave saw RX_SOF, RX_EOF. No RX_SFD, but RX_CRC on Port0.

    I still suspect RXD0-3 pins connectivity from Port0 PHY to PRUSS_MII0. You might want to probe these lines from PHY and make sure that there are no shorts etc. 

    Note that if RXD0-3 pins are connected to lcd_data8-11 then you need to select MUX_MODE = 5 and set MUX_SEL_REG = 0.

  • 0 in reply to PratheeshGangadhar
    Prodigy 30 points

    The problem appeared to be down to hardware. Our schematics/board has incorrect connection order for PRUETH0_RXD1-3. Once the signals were connected in correct order (lift the TLK110 pins and re-wire) the communication was successfully established.

     

    Thank you again for pointing us in the right direction.