DP83848-EP: ethernet connection between TMS320F28386D (dp83848) <-> window

Jaemin Yeo

Part Number: DP83848-EP

Tool/software:

Hi everyone, I have a question regarding Ethernet communication on a TI DSP board.

I’m currently working on sending and receiving packets between a TMS320F28x DSP board (connected to a DP83848 PHY) and a Windows PC. I'm referring to the TI example ethernet_ex2_phy_loopback.c as a base.

The DSP board is set to IP 192.168.1.2, and the Windows PC's Ethernet interface is set to 192.168.1.3. (I'll include the relevant initialization code at the end.)

On the DSP side, I initialize the Ethernet interface, configure the netif structure, and send packets by calling low_level_output, which internally sets up the packet descriptor like this:

pktDesc.bufferLength = total_len;
pktDesc.dataOffset = 0;

pktDesc.dataBuffer = Ethernet_txBuffer;
pktDesc.nextPacketDesc = 0;

pktDesc.flags = ETHERNET_PKT_FLAG_SOP | ETHERNET_PKT_FLAG_EOP | ETHERNET_PKT_FLAG_SA_INS;

pktDesc.pktChannel = ETHERNET_DMA_CHANNEL_NUM_0;
pktDesc.pktLength = total_len;

pktDesc.validLength = total_len;
pktDesc.numPktFrags = 1;


// Send packet

Ethernet_sendPacket(emac_handle, &pktDesc);

When I inspect the memory contents of Ethernet_txBuffer, I see the following Ethernet frame:

ff ff ff ff ff ff   01 02 03 04 05 06   08 06   <- Ethernet Header (Broadcast + Source MAC + ARP Type)

00 01 08 00 06 04 00 01                   <- ARP Header (Ethernet + IPv4 + MAC 6 bytes + IP 4 bytes)

01 02 03 04 05 06   C0 A8 01 02          <- Sender MAC/IP

00 00 00 00 00 00   C0 A8 01 02          <- Target MAC/IP

So far, this looks like a properly formatted ARP request packet.

However, when I capture packets using Wireshark on the Windows side, I see discrepancies in both the packet content and length. The frame doesn't match what I see in memory, and I'm unsure how the DSP is actually reading from the transmit buffer or if something is going wrong during transmission.

I’m having trouble figuring out what could be causing the mismatch. Any ideas on where the issue might be? How does the Ethernet peripheral read from the TX buffer internally? Any advice would be greatly appreciated.

+

Additionally, when I run the command "arping 192.168.1.2" from the Windows side toward the DSP board, it seems like the DSP (with the DP83848 module) is not receiving any incoming packets at all.

Isn't it expected that the DSP should receive the ARP request packet in this case?

Any advice on why no packets are being received would be greatly appreciated.

Initialization Code

void dsp_netif_init() {
    ip_addr_t ipaddr, netmask, gw;
    IP4_ADDR(&ipaddr, 192,168,1,2);

    IP4_ADDR(&netmask, 255,255,255,0);
    IP4_ADDR(&gw, 192,168,1,1);


    netif_add(&netif, &ipaddr, &netmask, &gw, NULL, ethernetif_init, ethernet_input);

    netif_set_link_up(&netif);

    netif_set_up(&netif);
    netif_set_default(&netif);

}


void Ethernet_init() {

    int i;

    initInterfaceConfig.ssbase = EMAC_SS_BASE;

    initInterfaceConfig.enet_base = EMAC_BASE;
    initInterfaceConfig.phyMode = ETHERNET_SS_PHY_INTF_SEL_RMII;


    initInterfaceConfig.ptrPlatformInterruptDisable = &Platform_disableInterrupt;

    initInterfaceConfig.ptrPlatformInterruptEnable = &Platform_enableInterrupt;

    initInterfaceConfig.ptrPlatformPeripheralEnable = &Platform_enablePeripheral;

    initInterfaceConfig.ptrPlatformPeripheralReset = &Platform_resetPeripheral;


    initInterfaceConfig.peripheralNum = SYSCTL_PERIPH_CLK_ENET;

    initInterfaceConfig.interruptNum[0] = INT_EMAC;

    initInterfaceConfig.interruptNum[1] = INT_EMAC_TX0;

    initInterfaceConfig.interruptNum[2] = INT_EMAC_TX1;

    initInterfaceConfig.interruptNum[3] = INT_EMAC_RX0;

    initInterfaceConfig.interruptNum[4] = INT_EMAC_RX1;

    pInitCfg = Ethernet_initInterface(initInterfaceConfig);

    Ethernet_getInitConfig(pInitCfg);

    pInitCfg->pfcbGetPacket = &Ethernet_getPacketBuffer;

    pInitCfg->pfcbFreePacket = &Ethernet_releaseTxPacketBuffer;

    pInitCfg->pfcbRxPacket = &Ethernet_receivePacketCallback;

    pInitCfg->rxBuffer = Ethernet_rxBuffer;

    pInitCfg->txBuffer = Ethernet_txBuffer;

    Ethernet_getHandle((Ethernet_Handle)1, pInitCfg, &emac_handle);

    Interrupt_enableInProcessor();

    Interrupt_registerHandler(INT_EMAC_TX0, Ethernet_transmitISR);

    Interrupt_registerHandler(INT_EMAC_RX0, Ethernet_receiveISR);

    Interrupt_enable(INT_EMAC_TX0);
    Interrupt_enable(INT_EMAC_RX0);

    Ethernet_configureMDIO(EMAC_BASE, 0, 5, 0);

    Ethernet_configurePHYAddress(EMAC_BASE, 1);

    SysCtl_delay(100000);

phyRegContent |= 0x1200;

// Auto-Negotiation enable + Restart

    Ethernet_writePHYRegister(EMAC_BASE, 0, phyRegContent);
    SysCtl_delay(100000);

Additional Info

When I scan PHY registers using this loop:

for (i = 0; i < 32; i++) {
    data = Ethernet_readPHYRegister(EMAC_BASE, i);
    printf("Found PHY at address: %d, 0x%04X \n", i, data);
}

I get the following output:

Found PHY at address: 0, 0x1000
Found PHY at address: 1, 0x7849
Found PHY at address: 2, 0x2000
Found PHY at address: 3, 0x5C90
Found PHY at address: 4, 0x01E1
Found PHY at address: 5, 0x0000
Found PHY at address: 6, 0x0007
Found PHY at address: 7, 0x2801
Found PHY at address: 8, 0x0000
Found PHY at address: 9, 0x0000
Found PHY at address: 10, 0x0000
Found PHY at address: 11, 0x0000
Found PHY at address: 12, 0x0000
Found PHY at address: 13, 0x0000
Found PHY at address: 14, 0x0000
Found PHY at address: 15, 0x0000
Found PHY at address: 16, 0x0000
Found PHY at address: 17, 0x0000
Found PHY at address: 18, 0x2C00
Found PHY at address: 19, 0x0000
Found PHY at address: 20, 0x0000
Found PHY at address: 21, 0x0000
Found PHY at address: 22, 0x0100
Found PHY at address: 23, 0x0021
Found PHY at address: 24, 0x0000
Found PHY at address: 25, 0x8021
Found PHY at address: 26, 0x0904
Found PHY at address: 27, 0x0000
Found PHY at address: 28, 0x0000
Found PHY at address: 29, 0x6011
Found PHY at address: 30, 0x083E
Found PHY at address: 31, 0x0000

5 months ago

0 Evan Su 5 months ago

TI__Mastermind 18950 points

Hi Jaemin,

I have assigned an engineer to answer your question. There is currently a TI US holiday so we will get back to you early next week.

Best,

Evan Su

0 Jaemin Yeo 5 months ago in reply to Evan Su

Prodigy 40 points

Evan Su said:
assigned

Thank you! Please leave a message when the engineer is assigned!

0 Gerome Cacho 5 months ago in reply to Jaemin Yeo

TI__Mastermind 39855 points

Hi Jaemin,

Please note that DP83848 is an older device and support is limited to datasheet.

I do notice that Reg 0x1 shows link down. This indicates that MDI link is not present and could be a reason why your ping test is not working. I see that the DUT is configured correctly (Auto-Negotiation is enabled in Reg 0x0, Advertisements are set in 0x4), but the DUT cannot receive the link partner's advertisements (Reg 0x5). This would tell me that either the link partner is not connected properly, or is not active.

Sincerely,

Gerome

0 Jaemin Yeo 5 months ago in reply to Gerome Cacho

Prodigy 40 points

Thank you for your previous answer. I have some additional questions based on the current situation.

Here is what I observe:

Found PHY at address: 0, 0x7100
Found PHY at address: 1, 0x7869
Found PHY at address: 2, 0x2000
Found PHY at address: 3, 0x5C90
Found PHY at address: 4, 0x01E1
Found PHY at address: 5, 0x4DE1
.
.
.
At 0x01, bit2 = 0 -> Link Status = 0
At 0x05, bit15 = 0 -> Link Partner does not desire Next Page Transfer
Q1)
What could be the cause of these results?
(Especially regarding the Link Status being 0 and the "Link Partner does not desire Next Page Transfer" status.)

Q2)
In the code, I found the following comment and setting:

// This way we ensure that the PTP clock is 100 MHz. Note that this value
// is not automatically/dynamically known to the CM core and hence it needs
// to be made available to the CM side code beforehand. SysCtl_setEnetClk(SYSCTL_ENETCLKOUT_DIV_2, SYSCTL_SOURCE_SYSPLL);
Since RMII requires a 50 MHz clock, and my DSP board is running at 200 MHz, wouldn't it make more sense to divide by 4 (instead of 2) to get 50 MHz?
I don't understand the explanation

Q3)
I have connected the DP83848’s OSCIN pin to the F2838x’s GPIO73 (ENET_RMII_CLK) pin.
In this case, is the DSP board providing the clock signal to the DP83848 module?
If so, should I set:

initInterfaceConfig.clockSel = ETHERNET_SS_CLK_SRC_INTERNAL;
instead of the default (EXTERNAL) setting?

thank you!

0 Gerome Cacho 5 months ago in reply to Jaemin Yeo

TI__Mastermind 39855 points

Hello,

Unfortunately, I am more of an expert for HW instead of SW. However, I do want to resolve the link issue before a colleague of mine would take a look a the SW.

The end objective would be to create MDI link for the PHY. For whatever reason, DUT is not able to see the LP's advertisements. It could be due to the link partner not being on, not advertising the correct settings, discontinuity, etc.

The DUT has the appropriate settings for communication (auto-negotiation enabled in 0x0, settings advertised in 0x4). Could you please send a schematic of the implementation for a quick check on the MDI?

Is there other link partners you could try out besides the PC? What cable (type and length) is being used?

Sincerely,

Gerome

Interface

Interface forum

DP83848-EP: ethernet connection between TMS320F28386D (dp83848) <-> window

Initialization Code

Additional Info