• State Resolved
  • Locked Locked
  • Replies 3 replies
  • Subscribers 30 subscribers
  • Views 2296 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.

LWIP 1.4.1 (pbuf.c) asserts error (p !=NULL) - locks EMAC (pbuf_pool) until MRST.

Genatco
Guru 56153 points

Other Parts Discussed in Thread: EK-TM4C1294XL

Anyone know what might cause intermittent (PBUF_POOL) error or what it means?

Debug error started showing up more often after installing memory leak patch (tiva-tm4c129.c).

ASSERT_FAIL at line 625 of C:/Software/Tivaware/TivaWare_C_Series-2.1.0.12573/third_party/lwip-1.4.1/src/core/pbuf.c: p != NULL

 

 

  • 0
    Guru 56153 points

    Why does the Exosite IOT client not have a callback argument, would not adding an argument stop intermittent assert error (p !=Null)?

      
    The Tiva schema (tiva-tm4c129.c) appears to be allocating (pcb) from PBUF_POOL  as if there is no throttle speed involved in how fast the PHY can move packets putting them on the wire. That schema may be fine for a 30Mbit UP pipe speed yet at 700Kbit UP data packet transfers can gets very congested even in Full Duplex Ethernet.

    LWIP configuration issues previously done by the Stellarisware group, migrated into (lwipopts.h) were and are fouling Cloud communications. LWIP is based on closely following RFC and other TCP info sources and MUST be properly configured to handle INTERNET communications broad scope of complexities that arise.

    There is extensive learning curve in the IOT madness flashed into the EK-TM4C1294XL.

    https://e2e.ti.com/support/microcontrollers/tiva_arm/f/908/t/450416

     

  • 0 in reply to Genatco
    Guru 56153 points

    We removed all call backs  { tcp_arg(pcb, NULL); } from the (lwip_eth_client) module and still get intermittent sanity check errors in (pbuf_pool) or worse, MPU resets. LWIP appears at times to blow up for no reason or Halts after long hours repeated connections of reading EEPROM. We then added a return call from read EEPROM during read Metadata.

    Users may have other ports in the application layer other than http 80 and much required hand shake blocking is needed for a multiport client model (tcp_write) & (tcp_read) into/from (tcp.c). A simple busy flag could block further (tcp_write) when or if busy buffering alternate ports packets. We now do alternate client Struct blocks only for (tcp_output) during LWIPHostTimerHandler() to avoid any unlikely crashes being the alternate port code is linear asserted time based.

    Oddly SRAM or EMAC transmitter appears hardware locked (latch up) no more pbuf_pool (*pcb) to or from the EMAC and hard reset MPU is only way to unlock EMACK transmitter or regain SRAM for build a new pbuf_pool.

    LWIP designs handles multiple TCP connections but only one port effectively, very hard to believe???

    ASSERT_FAIL at line 625 of C:/Software/Tivaware/TivaWare_C_Series-2.1.0.12573/third_party/lwip-1.4.1/src/core/pbuf.c: p != NULL

    Biggest clue:

    connect_to_exosite(): << Reading Flash stored meta data >>
ASSERT_FAIL at line 1006 of C:/Software/Tivaware/TivaWare_C_Series-2.1.0.12573/third_party/lwip-1.4.1/src/core/tcp.c: tcp_slowtmr: TIME-WAIT pcb->state == TIME-WAIT
ASSERT_FAIL at line 1006 of C:/Software/Tivaware/TivaWare_C_Series-2.1.0.12573/third_party/lwip-1.4.1/src/core/tcp.c: tcp_slowtmr: TIME-WAIT pcb->state == TIME-WAIT
ASSERT_FAIL at line 339 of C:/Software/Tivaware/TivaWare_C_Series-2.1.0.12573/third_party/lwip-1.4.1/src/core/mem.c: mem_free: mem->used
ASSERT_FAIL at line 650 of C:/Software/Tivaware/TivaWare_C_Series-2.1.0.12573/third_party/lwip-1.4.1/src/core/pbuf.c: pbuf_free: p->ref > 0
ASSERT_FAIL at line 339 of C:/Software/Tivaware/TivaWare_C_Series-2.1.0.12573/third_party/lwip-1.4.1/src/core/mem.c: mem_free: mem->used
ASSERT_FAIL at line 100Welcome to the Connected LaunchPad
Internet of Things Demo.
Type 'help' for help.
    ASSERT FAIL at line 619 of C:/Software/Tivaware/TivaWare_C_Series-2.1.0.12573/third_party/lwip-1.4.1/src/core/mem.c: mem_malloc: sanity check alignment
ASSERT FAIL at line 258 of C:/Software/Tivaware/TivaWare_C_Series-2.1.0.12573/third_party/lwip-1.4.1/src/core/pbuf.c: check p->payload + p->len does not overflow pbuf
ASSERT FAIL at line 825 of C:/Software/Tivaware/TivaWare_C_Series-2.1.0.12573/third_party/lwip-1.4.1/src/core/ipv4/ip.c: p->ref == 1
ASSERT FAIL at line 668 of C:/Software/Tivaware/TivaWare_C_Series-2.1.0.12573/third_party/lwip-1.4.1/src/core/ipv4/ip.c: p->ref == 1
ASSERT FAIL at line 320 of C:/Software/Tivaware/TivaWare_C_Series-2.1.0.12573/third_party/lwip-1.4.1/src/core/mem.c: mem_free: sanity check alignment
ASSERT FAIL at line 617 of C:/Software/Tivaware/TivaWare_C_Series-2.1.0.12573/third_party/lwip-1.4.1/src/core/mem.c: mem_malloc: allocated memory properly aligned.
ASSERT FAIL at line 619 of C:/Software/Tivaware/TivaWare_C_Series-2.1.0.12573/third_party/lwip-1.4.1/src/core/mem.c: mem_malloc: sanity check alignment
ASSERT FAIL at line 258 of C:/Software/Tivaware/TivaWare_C_Series-2.1.0.12573/third_party/lwip-1.4.1/src/core/pbuf.c: check p->payload + p->len does not overflow pbuf
ASSERT FAIL at line 320 of C:/Software/Tivaware/TivaWare_C_Series-2.1.0.12573/third_party/lwip-1.4.1/src/core/mem.c: mem_free: sanity Welcome to the Connected LaunchPad
Internet of Things Demo.
Type 'help' for help.

     

  • 0 in reply to Genatco
    Guru 56153 points

    A temporary work around at the application layer might include a block to hold off (tcp_write) until DMA transfers receive a return ACK from (tcp.c).  

    Inferring packets actually leave the PHY interface headed for wire bound journeys allocated (pcb) headers could return NAK to halt further DMA transfers? So de-allocated pcb header might be arbitrated and stuffed with an ACK preamble informing the network layer to wait on the device/physical layer when ever a pcb is packing a NAK in the preamble?

    Expecting packet exchange data transfer hand shaking to occur at the application layer was never the intent of the LWIP tcp stack embedded as the network layer.

    Some module in the pcb pool schema is not communicating busy status!

    This patch assumes the TCPwait flag is raised/lowered from any alternate named TCP port PCB struct list prior to asserting (tcp_write). Hence we then create a crude yet seamless noninvasive multi TCP port access method at the application layer.

    if((g_sEnet.eState == iEthSend) && (HWREGBITW(&g_sEnet.ui32Flags, iEthTCPWait) == 0)) 
 {
   //
   // Queue the send.
   //
   eError = tcp_write(g_sEnet.psTCP,
           g_pui8SendBuff + g_sEnet.ui32SendIndex,
                g_sEnet.ui32SendSize, TCP_WRITE_FLAG_COPY);