[TMSF320F28388D] Connectivity Manager(CM) Ethernet communication issue

Hi,

Thanks for the details. Can you let me know what is the MII mode you are operating on MII/RMII - 10/100mbps link?

Seung Seop Shin said:

The CM code works normally 1 : 1 (ICMP or UDP) : 1(EMAC)) communication. but a CRC, alignment and runt error occurs while N (ICMP, UDP, ...) : 1 (EMAC) communication.

In channels with more probability of CRC,other errors it may be ideal to use Normal Store and Forward of Ethernet module. Do you have a specific need to use low latency path like in ex10? Is your system not able to meet required latency with Store and forward mode like in other examples?

Seung Seop Shin said:

I assumed when EMAC sometimes receives an unrecognized packet, rx descriptor3 own bit(31) is 0 in rx interrupt. so I forcibly set own bit(31)in rx descriptor3 to 1 when rx packet that descriptor3 own bit(31) is 0 is received in rx interrupt.

It is not correct to do that, by doing so you are submitting the Buffer descriptor back to Rx DMA ring which may be the cause of your packets arriving out of order problem you mentioned above. It is advisable to fill back packets in sequential order in the Rx DMA ring. You should set it to 1 after programming other fields of the Receive normal descriptor. 

Seung Seop Shin said:

While N : 1 communication, what are some ways that the EMAC does not occur a CRC, alignment and runt error when receiving a packet?

The errors you mentioned may occur due to variety of reasons, ideally if the link is good you would not see such errors. wondering what is the other node Client N. What is your topology like F2838x directly connected to Client N or there are few more nodes in the network?

Seung Seop Shin said:

2. Likewise the above while N : 1 communication, what are some ways that the EMAC only occurs rx interrupt when receving normal packet like own bit(31) set 1 in rx descriptor3?

From ISR when you read the descriptor, OWN bit is set means the Rx DMA did not complete receiving the packet. In normal Error packets you would see that the OWN bit is cleared while reading the buffer descriptor from ISR. 

Seung Seop Shin said:

3. If I forcibly set own bit(31) to 1 when receiving a packet about own bit(31) set 0 in rx descriptor3, what are some ways that EMAC send to packet about receving the packet in correct order?

Setting the OWN bit alone in Rx ISR may not be sufficient. By doing so you are submitting that buffer to Hardware DMA engine again. you should do that after filling other fields. Otherwise it might result in packets not receiving in correct order. 

Hope it helps to debug your application further. 

Regards,

Sudharsanan

Thank you for your answer. I want to explain the current ethernet environment.

1. Currently, my board is set MII / 10mbps. 

2. In my code, the RxQ0 operation mode is threshold mode(default setting in ethernet sample ex10)

3. The client N are window processes(3 UDP client process, ICMP client process). physically, EMAC and Phy IC are wired by MII interface, and Phy IC and Windows PC are connected UTP cable.

As you answerd me, I test the code changing the Rx Q0 Operation mode to store-and-forward mode on ethernet sample ex10(\driverlib\f2838x\examples\cm\ethernet\ethernet_ex10_lowlatency_interrupt.c).

But if the communication continues for a while, the error(CRC, runt, alignment) is occurs, and the etherent rx interrupt routine is not called.

like the code below:

Ethernet_InitConfig *pInitCfg;

pInitCfg->numChannels = 1;
for(chIdx = 0; chIdx < pInitCfg->numChannels; chIdx++)
{
    //
    //Configure the TX in Threshold mode
    //
    pInitCfg->chInfo[ETHERNET_CH_DIR_TX][chIdx].storeNForward = \
                              ETHERNET_MTL_TXQ_OPMODE_TSF_DISABLE;
    pInitCfg->chInfo[ETHERNET_CH_DIR_TX][chIdx].dmaQueueSize =
                                ETHERNET_MTL_Q_OP_MODE_QSIZE_2048;

    //
    //Configure the IP in store-and-forward mode
    //For the RX Size
    //
    pInitCfg->chInfo[ETHERNET_CH_DIR_RX][chIdx].storeNForward =
                                        ETHERNET_MTL_RX_Q_OP_MODE_RSF_ENABLE;
    }
    pInitCfg->loopbackMode = ETHERNET_MAC_CONFIGURATION_LM_LOOPBACK_DISABLED;

    pInitCfg->dmaMode.InterruptMode = ETHERNET_DMA_MODE_INTM_MODE1;

    //
    //We are implementing our own ISR and hence this callback is not needed
    //
    pInitCfg->pfcbRxPacket = NULL;
    pInitCfg->pfcbGetPacket = &getPacketBuffer;

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

Hello, thank you for your answer.

I have tested the CM project based 'ethernet_ex2_phy_loopback.c'

I insert my rx function code to 'Ethernet_receivePacketCallback()' in ethernet.c(in driverlib_cm directory).

When my rx function(Ethernet_receivePacketCallback) is called, a packet in data buffer(in Ethernet_Pkt_Desc *pPacket) is inserted to my rx queue. and then dequeue the packet data in main loop(in main entry function) and send response packet data for replying using 'Ethernet_sendPacket()' in ethernet.c.

The logic is working in 1:1 communication(Windows PC : EMAC). however in 1:N communication(ICMP, 3 UDP clients : EMAC), N clients are received an another response packet not the response packet requested. especially when communication of a specific client is stopped, this situation is occured.

Ex) When ICMP process sends packet 1, packet2 and packet3, UDP process1 sends packet 4 and UDP process2 sends packet 5, the ICMP process receives response packet for packet2 and then receives reponse packet for packet 1, 3. the UDP process1 receives reponse packet for packet5 and the UDP process2 receives reponse packet for packet4.

How can I send the reponse packet in the order of request in 1: N communication? Is there any funtions elss I need to know except 'Ethernet_sendPacket' in ethernet.c?

+) in 1:N communication(ICMP, UDP), Rx_FIFO_Overflow_Packets register value may be over 0 

Hi,

Sorry for the delay in response due to global Lockdowns. Since you have already created a new thread with the last question. Let us discuss further there. 

Please refrain from posting same question on multiple threads instead ping on the same thread if you need response. 

Regards,

Sudharsanan