AM3356: PRU MII configuration for auto-forward mode

Hi Gunter,

The SORTE example in PDK includes the TX_AUTO_SEQUENCE configuration. Please refer to the macro M_SET_MIIRT_AF in icss_mirrt_macros.inc to see if any diff of TXCFG/RXCFG.

Regards,

Garrett

Hello Garrett

Thanks for your response. I looked at the macro you refer to. In our RXCFG0/TXCFG0 configuration we are doing almost same with some differences.

RXCFG0 was written with 0x0051 and TXCFG0 with 0x60400201 (See steps 9 and 10 in Gunter's post). Which of these differences do you think is causing the problem for us. In the macro, RXCFG0 has RX_CUT_PREAMBLE set to 1 in addition to what we configured and TXCFG0 had TX_MUX_SEL set to 1 in addition to what we had. Which of these differences matter? From the TRM we were under the impression that TX_MUX_SEL can be set to PRU0 or PRU1. Does Auto-forward configuration require that TX_MUX_SEL in TXCFG0 be set to 1 to select PRU1?

Thanks

Srini Dingari

Hi Srini,

Essentially TXCFG0 is for Port0 and TXCFG1 is for Port1. Unlike RXCFG which is based on PRUs, TXCFG is based on Ports.

PRU1 to transmit over Port0 => TX_MUX_SEL = 1 in TXCFG0

PRU0 to transmit over Port1  => TX_MUX_SEL = 0 in TXCFG1

There was some discussion on the TX/RXCFG in the thread - 

Regards,

Garrett

Hi Garrett

Thanks for the clarification. However, in auto-forward configuration, where PRUs are not involved and we are just forwarding from Rx Port to Tx Port, does it matter what the TX_MUX_SEL is. We are only connecting to one of the Ports that is connected to PRU0 MII signals. I assumed that if I setup auto-forward, then what I receive in Rx L1 FIFO from the Rx Port would be forwarded to the Tx Port that is connected to the same PRU. Hence I selected the TX_MUX_SEL for TXCFG0 as PRU0.

Hi Srini,

I wanted to check also on the underlying pinmux. Can you confirm that the pinmux is set correctly?

Thanks,

--Gunter

Hi Gunter,

Yes, I am assuming you are referring to the PRU MII-RT pin mux config. Yes, I did verify those. I will post the Pin Mux config shortly.

Hi Srini,

>>Does Auto-forward configuration require that TX_MUX_SEL in TXCFG0 be set to 1 to select PRU1?

It should not. The TX/RX MUX_SEL function can be seen in the Figure 4-32. MII_RT Block Diagram.

Is this still not working? Did you try to enable PRU through the PRUSS driver APIs? software-dl.ti.com/.../index_device_drv.html

/* Creates handle for PRUICSS instance */
handle = PRUICSS_create(pruss_config,instance);

/* Enable PRU */ 
PRUICSS_pruEnable(handle,0);

Regards,
Garrett 

Hi Garrett

Yes, it still does not work in Auto-Forward configuration. We are investigating if it's our target hardware issue.

Regarding enabling the PRUs, yes I did enable the PRUs similar to what was done in the PRUSS driver API. Please note that we are trying this on our target hardware not one of the AM335x kits. The following code sequence in our firmware is similar to what is found in pru software support package 5,7.0's pru.c file. (pru-software-support-package-5.7.0\pru_cape\pru_demo\StarterWare)

Here is the sequence.

 REG(AM335X_PRM_PER_REGS + PRM_PER_RSTCTRL) |= PRM_PER_RSTCTRL_ICSS_LRST;  // Reset PRU
 REG(AM335X_PRM_PER_REGS + PRM_PER_RSTCTRL) &= ~(PRM_PER_RSTCTRL_ICSS_LRST);   // Bring it out of Reset

 REG(AM335X_CM_PER_REGS + CM_PER_PRU_ICSS_CLKCTRL) |= CM_PER_PRU_ICSS_CLKCTRL_MODULEMODE_ENABLE;  // Enabling the PRU-ICSS module taking it out of idle

 REG(AM335X_PRM_PER_REGS + PRM_PER_RSTCTRL) |= PRM_PER_RSTCTRL_ICSS_LRST;  // Reset PR   REG(AM335X_PRM_PER_REGS + PRM_PER_RSTCTRL) &= ~(PRM_PER_RSTCTRL_ICSS_LRST);   // Bring it out of Reset

Setup the Pin Mux for MDIO and MII-RT pins. Basically selects Mode 5 for the PRU MDIO and PRU MII-RT pins.

Since we are presently interested in testing Auto-Forward configuration, we didn't load any firmware in either PRU so didn't enable either one. 
We just set up the PRU MII RXCFG/TXCFG registers for auto-forward from MII Rx Port to MII Tx Port.

In this configuration, we can see that the PRU MII is sending the Preamble and SFD out but the data is all 0's. We tried a loopback test within the PHY and and that worked so the data path until the PHY is working. It's just that the 
data received on PRU MII Rx port is not being forwarded to the Tx port in Auto-Forward mode. We did confirm using an O-Scope that Rx data is presented to the MII Rx pins and looked at the Tx data also.Rx data was as expected
but the Tx data only shows preamble and SFD.

Hi Srini,

OK, after you rule out hardware issue, you may try to set the bit 1 of CTRL register to 'enable processor' with a dummy PRU function to see if it behaves differently.

Regards,

Garrett

Hi Garrett

I actually had a small firmware loaded in both PRUs and both were enabled. I changed the firmware to continuously pop data from MII RX L1 FIFO with a delay between each but all I read is 0's. We are still not sure if it's the target hardware or some issue with the PRU/MII configuration.

Here is  a simple firmware sequence that I am running in a while loop. It runs in both PRUs and the rx_data is saved in the DRAM which I examine from the core (AM3356) and it is always 0s.

   __R31 = (1<<17);//rx_pop16

        __delay_cycles(400);

        rx_data = __R31;

Can you please let me know if reading data from the MII Rx L1 FIFO using the above sequence is ok?

Srini,

Please refer to the thread for the PRU code

Compiler/TMDSICE3359: PRU Ethernet issue - Processors forum - Processors - TI E2E support forums

e2e.ti.com

Part Number: TMDSICE3359 Other Parts Discussed in Thread: TLK110 , , AM3358 Tool/software: TI C/C++ Compiler Hello! I use the TMDSICE3359 board, TLK110

>>When I use the RX L1 FIFO -> TX L1 FIFI -> TX MII port data path mode it works fine with all computers.

Regards,
Garrett

Hi Garrett

I haven't heard back regarding my previous post on reading from the Rx L1 FIFO. Meanwhile, we tried another experiment to test if our target hardware is working.

I wrote PRU firmware to continuously send out a pre-assembled ARP frame. I reconfigured the PRU MII registers in normal mode (disabled Tx Auto-Sequence). With this firmware, we do see the data being partially sent out. We can see the preamble, SFD and some data bytes. However, some nibbles seem to be swapped or some are sent as 0's instead of actual data and the frame also doesn't get sent out completely.

Here is the transmit code that I wrote. I added a big delay of few ms between successive frame transmission because we thought we may be overwriting the FIFO before the data is transmitted but it didn't help. Arp_Frame in the following code is a 42-byte fixed ARP frame. I am sending 41 bytes in the for loop using TX_PUSH8 R31 command interface and then send the last byte outside the loop (I had it outside as initially I was setting the TX_EOF in the R31 command when this byte was pushed). I then write to R31 to append the CRC.  Can you please check the following code snippet and let me know if this is a valid transmit sequence or if there are any issues/suggestions.

   __R31 = TX_RESET;

   while (1)
   {
      data_p = (uint8_t *)&Arp_Frame;
      gpo = 0;

      for (i = 0; i < (sizeof(Arp_Frame))-1; i++, data_p++) 
      {
         gpo = *data_p;
         __R30 = 0xFFFF0000 | gpo; //TX mask to transmit data from R30, not RX FIFO
         __R31 = TX_PUSH8; //push to the mii tx
         Packet[i] = gpo&0xff;
      }

      /* Send the last byte */
      gpo = *data_p;
      __R30 = 0xFFFF0000 | gpo; //TX mask to transmit data from R30, not RX FIFO
      __R31 = ( TX_PUSH8 ); //push to the mii tx, EOF_TX, send the pack finish

      __delay_cycles(4);

      __R31 = ( TX_CRC_HIGH | TX_CRC_LOW); //push to the mii tx, EOF_TX, send the pack finish
      Packet[i++] = gpo&0xff;

        __delay_cycles(3000000);

   }

Thanks 

Srini Dingari

Srini,

I reached out to the SORTE developer and realized that the device AM3356 is not a EtherCAT capable device (). For MII auto-forward to work, you need an EtherCAT enabled devices. Otherwise this feature is disabled.

You may try the feature on TI AM3359 ICE v2 device.

Regards,

Garrett

Thanks for the clarification Garrett. However, the Technical Reference Manual (spruh73q) is not very explicit about the Auto-Forward/Auto-Sequence not being available in products without the EtherCAT capability,. I was going strictly by the TRM and trying to implement the Auto-Forward configuration for our initial target hardware testing.

I would still need some help/guidance with the PRU MII Tx/Rx. I am referring to the ICSS Dual Emac and Switch configuration firmware but we are unable to use it as-is because we use a different OS and Ethernet Stack, so we have to write our own PRU firmware for MII Tx/Rx.

Thanks

Srini

Hi Garrett

As per your confirmation that Auto-Forward is not supported in AM3356, I stopped using that configuration and trying to write a small firmware initially to receive and echo back the received frames for testing our target hardware but having issues. I will open another thread as you suggested.

Please review and let me know.

Thanks

Srini

Here is the link to the other thread I opened regarding RX_EOF indication.