F28M35H52C: enet_lwip "Hard Fault"

Hi Linda,

The solution that was described by the other forum is this:

Include the following clause within lwIPEthernetIntHandler(void):

    // Handle receive error or FIFO overrun
    if  ( (ulStatus & (ETH_INT_RXOF|ETH_INT_RXER) ) != 0 )
    {
     unsigned long ethReceiveControl = HWREG(ETH_BASE + MAC_O_RCTL);
     // Disable receiver
     ethReceiveControl &= ~(MAC_RCTL_RXEN);
     HWREG(ETH_BASE + MAC_O_RCTL) = ethReceiveControl;
     // Clear receive FIFO
     HWREG(ETH_BASE + MAC_O_RCTL) |= MAC_RCTL_RSTFIFO;
     HWREG(ETH_BASE + MAC_O_RCTL) |= MAC_RCTL_RSTFIFO;
     // Enable receiver
     ethReceiveControl = HWREG(ETH_BASE + MAC_O_RCTL);
     ethReceiveControl &= ~(MAC_RCTL_RSTFIFO);
     ethReceiveControl |= MAC_RCTL_RXEN;
     HWREG(ETH_BASE + MAC_O_RCTL) = ethReceiveControl;
     return;
    }

Did a more careful check of receive length within concertoif_receive(struct netif *netif):

    p = NULL;

  /**
   * Obtain the size of the packet and put it into the "len" variable.
   * Note:  The length returned in the FIFO length position includes the
   * two bytes for the length + the 4 bytes for the FCS.
   *
   */
  temp = HWREG(ETH_BASE + MAC_O_DATA);
  len = temp & 0xFFFF;
  LWIP_ASSERT("Packet length too short", len >= 4);

    if ( (len >= 46) && (len <= 1504) )
    {
     /* We allocate a pbuf chain of pbufs from the pool. */
     p = pbuf_alloc(PBUF_RAW, len, PBUF_POOL);
    }

Is this what was tried?

Hello Yashwant,

Thank you for your kind help.

Customer tried the solution you provided and after testing for several hours, there was no "Hard fault" during the test.    

But there was certainly receive FIFO flow for M3 and when this kind of overflow happened, it will disable receive, clear FIFO and enable receive again while this procedure may lead to data loss or timeout failure.

Would you please kindly suggest how to deal with this FIFO overflow issue? Thanks!

Best Regards,

Linda

Hello Yashwant,

Would you please kindly help? Thanks!

Best Regards,
Linda

Hello Yashwant,

Customer required to keep the testing condition and not to change the settings of interpacket delay.

They tested with the same condition on TM4C129x board and this FIFO overflow will not occur.

Would you please kindly suggest what about the difference for receive FIFO configuration on M3 of F28M35 and TM4C129x? Is there any FIFO related configuration they can modify on M3 of F28M35 to solve this overflow issue? 

Thanks!

Best Regards,

Linda

Hi Linda,

We are comparing 125 Mhz stack TM4C129x with F28M35x 100Mhz stack. Even if the IP Versions are same drop in the packets are expected because of the latency increment in the processing of new received packets.

Thanks,

Yashwant

Hello Yashwant,

Thank you for you kind help.

Customer still had below questions:

1) Regarding TM4C129x demo codes configuration, it used DMA for Ethernet, but for demo codes of M3 in F28M35, there is no DMA configuration for Ethernet. Since uDMA has been mentioned for Ethernet in F28M35 user manual, are there any demo codes to show how to use uDMA for Ethernet? Does the DMA make TM4C129x more efficient on data receiving?

2) Does CPU frequency difference between TM4C129x and M3 of F28M35 also a main cause for this issue since the structure of both demo codes are very similar?

Would you please kindly help again? Thanks!

Best Regards,

Linda

Hello Yashwant,

Would you please kindly help again? Thanks!

Best Regards,

Linda

Hi Linda,

1) F28M35 also uses uDMA to receive packets from the fifo. So its not because of DMA efficiency.

2) Yes the CPU frequency difference between TM4C129x and F28M35 could be the main cause for faster fifo overflow.

Thanks,

Yashwant