AM2434: PRUICSS1 IEP0 EDC_LATCH0 Signal disrupts PRUICSS0 Rgmii transmit

Hi Lucas,

This is not expected. We will check this and comeback

Regards,
Prajith

Hi,

thanks for the reply.

1. We are using a custom board with icssg0 mii0 rgmii signals lines connected to a fpga and icssg1 lines needed for ethercat routed to cpb connectors but currently not connected to anything, PRG1_IEP0_EDC_LATCH_IN0 is connected to a male header and the fpga, its stable high on default and can be pulled down by directly connecting to ground

2.

-ICSSG0 MII0:
  - speed: 1gbps
  - full duplex
  - custom pru firmware that is based of the sorte_g firmware

- The output is observed by writing data to memory of the fpga and reading it back via SPI0

3. I verified with over 1M communication cycles (Writing over rgmii and reading back over SPI0) that the data i correctly transmit if the  PRG1_IEP0_EDC_LATCH_IN0 is low, either by pulling it low with a cable to ground or by defining the pin as output and driving it actively low

4. Since the ethercat is not implemented yet the pin is always high if not specially put to zero, i couldnt observe any changes in the signal while transmitting rgmii data using an oscilloscope 

Out pcb design doesn't allow to directly observe the rgmii data wires, so i cant check if there is a difference in the signal when PRG1_IEP0_EDC_LATCH_IN0  is high.

Thank you for your support.

Regards
Lucas

Hi Lucas,

Thanks for your response. I am planning to reproduce the issue locally on a TI board to ensure that its not a board specific issue. 

In the meantime, I will also check with the team internally if there are some known issues which could help explain this behavior.

Please expect a response next week.

Thank you for your patience.

Regards
Archit

Hi Lucas,

As I mentioned, I am discussing this with the SORTE Team and they've requested for the following information to isolate the issue better.

1. Which SORTE_G firmware variant you're using?
   1. SORTE_G Device
   2. SORTE_G Controller
2. If possible, can you provide the SORTE_G firmware version you've used as a baseline for your development?
3. Are you using the ICSS IEP PDI Watchdog in your implementation? 

Regards
Archit

Hi Archit,

1. I based my pru firmware on the SORTE_G Controller firmware, but i only reused the rgmii/mii register config, 32Byte send function and receive tasks
2. I cant provide it here directly but here is a complete run down on the used components and their configuration:
- MII/RGMII in 1gbps full duplex mode with L2 activated and in 32Byte mode
- xfr2vbus in mode 0x6 for copying the send data from msram to pru ram in 64byte blocks
- pru taskmanager in eth mode for the receive, receive tasks taken from sorte_g controller and modfied to directly move the received data to msram
3. Im not using ICSS IEP PDI Watchdog in my pru driver

Regards
Lucas

Hi Lucas,

Thank you for the response. I'll discuss this with the team and get back to you with an update.

Regards
Archit

Hi Lucas,

One suggestion from the team is that the observed issue could also be pin level interference. Can you check if the Latch input pin is close to the RGMII Tx pins at the SoC pinmux level?

Regards
Archit

Hi Archit,

Thanks for your reply. I have to work on a different topic for now. I will come back with some measurements as soon as possible. The Latch is close to one of the TX lines but on a different layer, so we don`t expect problems there. 

Regards
Lucas