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.

TM4C1294NCPDT: TM4C1294NCPDT

Part Number: TM4C1294NCPDT


Hello,

My application intends to generate PWM signals at 250 KHz and the samples are supplied in real time through Ethernet using UDP Protocol. Device: TM4C1294NCPDT

I used the enet_uip example to build my code. Currently I'm able to receive packets and generate the required PWM Signals, but due to network delays from sending PC, I'm not able to maintain the fidelity of the generated signal. In the present code, I'm using 3 Ethernet Receive Descriptors with code line  #define NUM_RX_DESCRIPTORS 3.

Now I would like to increase the number of receive buffers to 6 or 12 to solve the issue. I did this by simply changing the code #define NUM_RX_DESCRIPTORS 12. The code is compiling without errors, but the ethernet reception is not happening in microcontroller.

So my question is how to increase the number of receive descriptors to 12. 

In the comments section of enet_uip.c, it is mentioned that

"// The MAC hardware needs a minimum of 3 receive descriptors to operate. The
// number used will be application-dependent and should be tuned for best
// performance."

Request to help me in this regard.

Thanks in advance. 

  • Hi,

      I'm not sure. I'm wondering if you set NUM_RX_DESCRIPTORS to 4 or 5 or 6, will it make a difference. Having said that, I really doubt your issue is related to number of descriptors. Each descriptor can potentially transfer up to a Ethernet frame of data which is about 1500 bytes. If the data you receive is meant to only change the duty cycle of a PWM signal then I don't think increasing the number of descriptors will benefit any performance. 

     Why don't you first look at the descriptor list? Are the 12 descriptors correctly chained together? Is the last descriptor indicating as the last one in the chain?

      I will suggest you single step and place breakpoint in the interrupt and in line where PacketRecieve is called. 

  • Hi,

    With 3 DESCRIPTORS, I'm able to receive and generate the required PWM Signals. If I can increase the number of receive buffers, small jitters in UDP sending from PC will have no effect. And that is the reason why I would like to increase the number of DESCRIPTORS. 

    So any value higher than 3 for NUM_RX_DESCRIPTORS will help. 

    Does anyone in the forum has used a value higher than 3 for NUM_RX_DESCRIPTORS and how to do this. Any code examples available?

  • All I can tell is that the way it is coded, all three RX descriptors all point to the same buffer. If you look at what I capture when I run the same example, the three descriptors all point to the same buffer at 0x20000644. This is matching the comments in the example where it says by design, the uIP only uses a single buffer. The reason that three descriptors are used is to satisfy the hardware requirements that is not related to uIP. Therefore, increasing the number of descriptors, I don't think it will help from uIP perspective. I have hardly seen people use uIP to begin with in the forum, let alone asking questions what the performance would be if increasing the number of descriptors. Have you tried 4 or 5 descriptors? What is the result?

  • I tried increasing the number of Descriptors to 4 and more by just changing the code line:

    #define NUM_RX_DESCRIPTORS 4.

    But then I'm not able to receive any packets and even the packet transmission from the uC stops. 

  • I don't know what else did you change. Note the example is only a simple webserver. You probably change something other than just NUM_RX_DESCRIPTORS . 

    I change both the TX and RX to 12 and run the example. I don't see any problem. 

    #define NUM_TX_DESCRIPTORS 12
    #define NUM_RX_DESCRIPTORS 12

    As I mentioned, uIP only uses one buffer even if you reserve 3 or 12 will not help per comments from the example. If you look at 12 descriptors, they all point to the same buffer. 

    I will suggest you use wireshark to understand your problem.

  • Hi,

    I modified the uip code sections with the example provided in Tivaware Userguide. But if you see the code section in userguide there is small (yet problematic) error with TX and RX interchanged for the buffer as in image below. 

     

    I corrected this interchange of TX and RX. Even then it was not able receive and transmit packets. But when I checked with debug, 12 buffers were assigned as it is shown in the earlier reply. I'm attaching the code section of buffers and descriptor initialization. 

    //*****************************************************************************
    //
    // Ethernet DMA descriptors.
    //
    // The MAC hardware needs a minimum of 3 receive descriptors to operate. The
    // number used will be application-dependent and should be tuned for best
    // performance.
    //
    //*****************************************************************************
    #define NUM_TX_DESCRIPTORS 3
    #define NUM_RX_DESCRIPTORS 24
    tEMACDMADescriptor g_psRxDescriptor[NUM_RX_DESCRIPTORS];
    tEMACDMADescriptor g_psTxDescriptor[NUM_TX_DESCRIPTORS];
    uint32_t g_ui32RxDescIndex;
    uint32_t g_ui32TxDescIndex;
    
    #define RX_BUFFER_SIZE 1536
    uint8_t g_ppui8RxBuffer[NUM_RX_DESCRIPTORS][RX_BUFFER_SIZE];
    
    
    
    void
    InitDescriptors(uint32_t ui32Base)
    {
    		uint32_t ui32Loop;
    	
    		// Initialize each of the transmit descriptors. Note that we leave the
    		// buffer pointer and size empty and the OWN bit clear here since we have
    		// not set up any transmissions yet.
    		//
    		for(ui32Loop = 0; ui32Loop < NUM_TX_DESCRIPTORS; ui32Loop++) {
    			g_psTxDescriptor[ui32Loop].ui32Count = DES1_TX_CTRL_SADDR_INSERT;
    			g_psTxDescriptor[ui32Loop].DES3.pLink = (ui32Loop == (NUM_TX_DESCRIPTORS - 1)) ?
    											g_psTxDescriptor : &g_psTxDescriptor[ui32Loop + 1];
    			g_psTxDescriptor[ui32Loop].ui32CtrlStatus = (DES0_TX_CTRL_LAST_SEG | DES0_TX_CTRL_FIRST_SEG |
    					DES0_TX_CTRL_INTERRUPT | DES0_TX_CTRL_CHAINED |
    					DES0_TX_CTRL_IP_HDR_CHKSUM);
    		}
    		//
    		// Initialize each of the receive descriptors. We clear the OWN bit here
    		// to make sure that the receiver doesn t start writing anything
    		// immediately.
    		//
    		for(ui32Loop = 0; ui32Loop < NUM_RX_DESCRIPTORS; ui32Loop++)
    		{
    		g_psRxDescriptor[ui32Loop].ui32CtrlStatus = 0;
    		g_psRxDescriptor[ui32Loop].ui32Count = (DES1_RX_CTRL_CHAINED |
    										(RX_BUFFER_SIZE << DES1_RX_CTRL_BUFF1_SIZE_S));
    		g_psRxDescriptor[ui32Loop].pvBuffer1 = g_ppui8RxBuffer[ui32Loop];
    		g_psRxDescriptor[ui32Loop].DES3.pLink = (ui32Loop == (NUM_RX_DESCRIPTORS - 1)) ?
    					g_psRxDescriptor : &g_psRxDescriptor[ui32Loop + 1];
    		}
    		//
    		// Set the descriptor pointers in the hardware.
    		//
    		EMACRxDMADescriptorListSet(ui32Base, g_psRxDescriptor);
    		EMACTxDMADescriptorListSet(ui32Base, g_psTxDescriptor);
    		//
    		// Start from the beginning of both descriptor chains. We actually set
    		// the transmit descriptor index to the last descriptor in the chain
    		// since it will be incremented before use and this means the first
    		// transmission we perform will use the correct descriptor.
    		//
    		g_ui32RxDescIndex = 0;
    		g_ui32TxDescIndex = NUM_TX_DESCRIPTORS - 1;
    }

    Then I copied the emac.c and emac.h into my sourcecode folder and added these file to my project. Then compiled and downloaded. Surprisingly it worked. 

    Thanks for the support extended.