• State Resolved
  • Locked Locked
  • Replies 17 replies
  • Subscribers 98 subscribers
  • Views 3184 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.

AM3358: [EMAC] Unable to transmit Ethernet packets

Khalid al shamkhany
Prodigy 170 points
Other Parts Discussed in Thread: AM3358

Hi,


I'm trying to setup the Ethernet subsystem. So far I have been successful in receiving packets, however I am not able to transmit packets.

Before transmitting a packet, I prepare a buffer descriptor with buffer length & and the other required parameters and then I write to the TX0_HDP register to initiate the transmission. After sometime, I get TX interrupt on channel 0 indicating the transmission is complete. However, when I look at the STATS register all of the TX FRAME counters are zero and nothing has been transmitted. When I check the DMASTATUS register I see no errors. Status generation is enabled for all ports.

I have the ALE subsystem enabled and put in bypass mode. Does that cause an issue when transmitting packets?     

I also noticed on the STATS register that every time I attempt to transmit the carrier sense error counter increase.

Thanks,

Khalid

  • 0
    TI__Mastermind 27743 points
    Hello Khalid,

    For transmit operation ALE configuration should not matter.
    - Are you running in half-duplex mode?
    - Do you see in stats if any other counter related to TX like rx_inderrun increasing?
    - What is contents of SL_Control and TX0_CP register?
    - You may like to check if the TX descriptor is configured correctly. There is field like ownership field etc. which should be configured correctly.
  • 0 in reply to Prasad Jondhale
    Prodigy 170 points
    Hi Prasad,

    Thanks for the reply.

    - Are you running in half-duplex mode? I think I am. the PHY chip status registers say the link is 100 FULL DUPLEX. Also, I have the FULLDUPLEX bit in the MACCONTROL register of port 1 set to 1. How else I can check?

    Do you see in stats if any other counter related to TX like rx_inderrun increasing? NONE of the TX counters is increasing

    What is contents of SL_Control and TX0_CP register? SL_Control is MACCONTROL right? If so, it's 0x00000021

    The TX0_CP points to the buffer descriptor address that finished. The thing is I get transfer complete interrupts and the TX0_HDP register clears

    You may like to check if the TX descriptor is configured correctly. There is field like ownership field etc. which should be configured correctly.

    I have the following flags set in the buffer descriptor: SOP, EOP, OWN, TO_PORT_EN, port 1 selected, and packet length
    When the packet is transmitted the OWN flag clears and EOQ flag sets

    Regards,
    Khalid
  • 0 in reply to Khalid al shamkhany
    TI__Mastermind 27743 points

    Hello Khalid,

    From the register details it looks like your EMAC configuration is all correct. The packet drop can be because of incorrect PHY configuration.

    1. Which MAC mode you are configuring? is it MII?

    2.Which PHY are you using? What is content of BMCR(control reg) & BMSR(Status reg)?

    3. Please check contents of SLSTATUS register to see if EXT_GIG is not set. (share register contents)

    4. Please check if PAD configuration is done correctly for TX. 

    5. Though should not matter, can you please disabling TO_PORT_EN in TX descriptor?

  • 0 in reply to Prasad Jondhale
    Prodigy 170 points

    Hi Prasad,


    Thank you for your time in assisting me sorting this.

    Prasad Jondhale said:
    From the register details it looks like your EMAC configuration is all correct. The packet drop can be because of incorrect PHY configuration.

    If EMAC configuration is all correct, then shouldn't the STATS registers TX counters increase cuz I believe the STATS registers are gathering statistical data for what's going on inside the EMAC_SS, and not the PHY unit.

    Prasad Jondhale said:
    1. Which MAC mode you are configuring? is it MII?

    Yes, it's MII mode

    Prasad Jondhale said:
    2.Which PHY are you using? What is content of BMCR(control reg) & BMSR(Status reg)?

    I'm using the Beaglebone Black board, which has the LAN8710A PHY unit. The registers content are


    Reg 0 (BMCR) =  0x00003000

    Reg 1 (BMSR) =  0x00007809

    Prasad Jondhale said:
    3. Please check contents of SLSTATUS register to see if EXT_GIG is not set. (share register contents)

    It's not set (0)

    Prasad Jondhale said:
    4. Please check if PAD configuration is done correctly for TX. 

    This is my PAD setup code:

    	/*
	 * Configure pin MUX
	 */

	/* MDIO pins */
	HWREG(SOC_CONTROL_REGS + CONTROL_CONF_MDIO_CLK) = (1 << 4); // output pull up
	HWREG(SOC_CONTROL_REGS + CONTROL_CONF_MDIO_DATA) = ((1 << 5) | (1 << 4)); // pullup, input/output

	/* MII1 TX pins */
	HWREG(SOC_CONTROL_REGS + CONTROL_CONF_MII1_TXCLK) = ((1 << 5) | (1 << 4)); 	 // MII1_TXCLK
	HWREG(SOC_CONTROL_REGS + CONTROL_CONF_MII1_TXEN) = (1 << 4);				 // MII1_TXEN
	HWREG(SOC_CONTROL_REGS + CONTROL_CONF_MII1_COL) = ((1 << 5) | (1 << 4));	 // MII1_COL
	HWREG(SOC_CONTROL_REGS + CONTROL_CONF_MII1_CRS) = ((1 << 5) | (1 << 4));	 // MII1_CRS
	HWREG(SOC_CONTROL_REGS + CONTROL_CONF_MII1_TXD0) = (1 << 4); 				// MII1_TXD0
	HWREG(SOC_CONTROL_REGS + CONTROL_CONF_MII1_TXD1) = (1 << 4); 				// MII1_TXD1
	HWREG(SOC_CONTROL_REGS + CONTROL_CONF_MII1_TXD2) = (1 << 4); 				// MII1_TXD2
	HWREG(SOC_CONTROL_REGS + CONTROL_CONF_MII1_TXD3) = (1 << 4); 				// MII1_TXD3

	/* MII1 RX pins */
	HWREG(SOC_CONTROL_REGS + CONTROL_CONF_MII1_RXCLK) = ((1 << 5) | (1 << 4)); 	// MII1_RXCLK
	HWREG(SOC_CONTROL_REGS + CONTROL_CONF_MII1_RXDV) = ((1 << 5) | (1 << 4)); 	// MII1_RXDV
	HWREG(SOC_CONTROL_REGS + CONTROL_CONF_MII1_RXERR) = ((1 << 5) | (1 << 4)); 	// MII1_RXER
	HWREG(SOC_CONTROL_REGS + CONTROL_CONF_MII1_RXD0) = ((1 << 5) | (1 << 4)); 	// MII1_RXD0
	HWREG(SOC_CONTROL_REGS + CONTROL_CONF_MII1_RXD1) = ((1 << 5) | (1 << 4)); 	// MII1_RXD1
	HWREG(SOC_CONTROL_REGS + CONTROL_CONF_MII1_RXD2) = ((1 << 5) | (1 << 4)); 	// MII1_RXD2
	HWREG(SOC_CONTROL_REGS + CONTROL_CONF_MII1_RXD3) = ((1 << 5) | (1 << 4)); 	// MII1_RXD3

	/* MII Reference clock */
	HWREG(SOC_CONTROL_REGS + CONTROL_CONF_RMII1_REFCLK) = ((1 << 5) | (1 << 3)); // RXACTIVE, PUPD disabled

    Prasad Jondhale said:
    5. Though should not matter, can you please disabling TO_PORT_EN in TX descriptor?

    I tried and it did not help

    Thanks

    -Khalid

  • 0 in reply to Khalid al shamkhany
    TI__Mastermind 27743 points

    Hello Khalid,

    The Basic Status Register (bit 5) shows that auto-negotiate process is not completed for PHY. Also the link status shows link is not up. Dont know why receive is working.

    Please through BCR try re-starting auto-negotiation or changing speed setting.

    Confirm SPECIAL MODES REGISTER shown PHY is configured in MII mode (done through pin-strapping). Also confirm transceiver MODE in same register.

    Confirm contents of PHY SPECIAL CONTROL/STATUS REGISTER matching what you are configuring.

  • 0 in reply to Prasad Jondhale
    Prodigy 170 points

    I think I forgot to re-connect the cable when I read register values to post them here. Anyway those are the correct values:

    Reg 0 = 0x00003100
    Reg 1 = 0x0000782D

    Regards,

    Khalid

  • 0 in reply to Khalid al shamkhany
    TI__Mastermind 27743 points

    Khalid,

    Both MAC and PHY are correctly configured (as evident from PHY settings). I was guessing issue is because of mismatch between MAC and PHY configuration.

    Now only reason for carrier sense errors to occur following scenarios
    1. Half duplex Ethernet mode and heavy rx/tx traffic
    2. The connect link issue (faulty remote NIC issue)
    3. N/w cable
    4. Faulty switch port.

    You need to check for all above Like try changing remote connection (instead of connecting to switch connect to PC etc), change cable use CAT6.

  • 0 in reply to Prasad Jondhale
    Prodigy 170 points
    I have the time sync module (CPTS) disabled, and the TX_FLOW_EN & RX_FLOW_EN are also disabled. Perhaps they must be enabled for TX to work?

    -Khalid
  • 0 in reply to Khalid al shamkhany
    TI__Mastermind 27743 points
    I dont think so. CPTS for sure has no effect. You can try TX_FLOW_EN.
    But I would suggest finding issues in 4 scenarios mentioned in earlier post.
  • 0 in reply to Prasad Jondhale
    Prodigy 170 points
    I just noticed that there are no longer CRS errors, and that's because I fixed a bug in my code where the FULLDUPLEX in my code wasn't being set in the initialization code sometimes.

    However, this did not solve the problem of the transmission. The TX counters NEVER increase. Reception is working. I get RX interrupts , process them. and send TX packet. I get TX packet transmission complete interrupt. I check the DMASTATUS register and see no errors. But nothing is transmitting!

    The TRM says the "GOOD_TX_FRAMES" counter is:

    The total number of good frames received on the port. A good frame is defined to be:
    • Any data or MAC control frame which matched a unicast, broadcast or multicast address, or matched
    due to promiscuous mode
    • Any length
    • Had no late or excessive collisions, no carrier loss and no underrun

    All of the above is checked. So how come it's not incrementing?

    Regards,
    Khalid
  • 0 in reply to Khalid al shamkhany
    TI__Mastermind 27743 points
    If you are getting TX interrupt and TX0_CP value is TX0_HDP (for single packet transfer), then there is no reason for stats not to increase unless stats are not ebabled for that port. Is the value of PSW_STAT_PORT_EN 0x7?
    Is it possible to probe Tx signals? You can check if TX clk and other data pins are toggling.
  • 0 in reply to Prasad Jondhale
    Prodigy 170 points
    I don't have access to an oscilloscope. Yes, the PSW_STAT_PORT_EN is 0x7. Are there stats registers for each port? I am using CCS debug mode to view the values of the stats registers. The PHY unit is connected to PORT 1 on the Beaglebone Black board. I did not configure PORT 2(SL2) -Khalid
  • 0 in reply to Khalid al shamkhany
    TI__Mastermind 27743 points
    The stats regs are common for all ports. You can mask stats for particular port using STAT_EN register.
    Can you connect PC with wireshark at the other end of board? check if you are receiving any packets in wireshark.
  • 0 in reply to Prasad Jondhale
    Prodigy 170 points
    I just checked with Wireshark. I see I am sending packets, but I'm not getting any from the AM3358. Are you sure ALE being in bypass mode does not affect packet transmission?

    -Khalid
  • 0 in reply to Khalid al shamkhany
    TI__Mastermind 27743 points

    Yes, ALE bypass does not have effect on packet TX as long as ALE_PORTCTL for ports in use in FORWARD state.

  • 0 in reply to Prasad Jondhale
    Prodigy 170 points

    Aaaaaaaaaaaaand that was the problem! the ports weren't in the FORWARD state. Transmission is working now. Thanks a lot!

    How come this isn't mentioned any where in the TRM?

  • 0 in reply to Khalid al shamkhany
    TI__Mastermind 27743 points
    It is mentioned in Packet Forwarding Processes subsection of ALE, though not explicitly.