enet_lwip and UART problems

Hi Martin,

I had an issue with LWIP (enet_lwip) where after some web pages were loaded, the LWIP (with an incoming page request) didn't have enough memory to store the connection state. The client browser went into a connection loss event. To determine if this is your situation, in the http.c file look for function http_accept() and locate the following

  /* Allocate memory for the structure that holds the state of the
     connection - initialized by that function. */
  hs = http_state_alloc();
  if (hs == NULL) {
    LWIP_DEBUGF(HTTPD_DEBUG, ("http_accept: Out of memory, RST\n"));
    return ERR_MEM;
  }

On the line "return ERR_MEM" place a breakpoint. If you hit that breakpoint, then your having a memory starvation situation like I had.

I fixed the problem by enabling these two defines in the lwipopts.h file and used my own memory pools.

#define MEM_USE_POOLS                                 1
#define MEMP_USE_CUSTOM_POOLS           1

Hope this helps,

Alan

Hi Alan,

Can you post the custom pools (lwippools.h) you created for use with LWIP.  We struggled to get the proper syntax (below) for each independant pool (macro) and instead bumped the HEAP size up to 32kb in lwipopts.h

* To let mem_malloc() use pools (prevents fragmentation and is much faster than a heap but might waste some memory), define MEM_USE_POOLS to 1, define MEMP_USE_CUSTOM_POOLS to 1 and create a file "lwippools.h" that includes a list of pools like this (more pools can be added between _START and _END):

Sample (lwippools.h):

#if MEMP_USE_CUSTOM_POOLS

#define LWIP_MALLOC_MEMPOOL_START
#define LWIP_MALLOC_MEMPOOL (PBUF, MEMP_NUM_PBUF, 0, "PBUF_REF/ROM")
#define LWIP_MALLOC_MEMPOOL (RD_PBUF_POOL, PBUF_POOL_SIZE, 512, "PBUF_POOL_1")
#define LWIP_MALLOC_MEMPOOL (RD_PBUF_POOL, PBUF_POOL_SIZE, 600, "PBUF_POOL_2")
#define LWIP_MALLOC_MEMPOOL_END

#endif

Hi BocaDev,

With the standard 32k heap it starts at 9386k grows 12k and upward after many hours of operation. Only a few KB ever get returned to the heap and it never compresses once it hits a peak it grows even more. So (mem_free) is not doing a very good job at heap management or it getting so highly fragmented with broken chains TCP just crashes at some point many days out.

Tried those similar above even adding (#defines) on  each line but get an incompatible redefinition of macro (lwip_malloc_mempool) for the 2nd/3rd pools and (memp_std.c/h) still refuses to build with out errors.  Most the errors indicate the default (memp_pbuf_pool) has already been declared in the current scope even after setting custom/use pools  = 1.  LWIP v.1.4.1

The default macro (lwip_pbuf_mempool) is some how bound to (mem_pbuf_pool) which uses type (PBUF_RAM) stored in the heap configured for the DMA descriptors by invoking lwip Pbuf allocator in (tiva-tm4c129.c). There must be more to the LWIP configuration settings to use custom pools?

The default (pbuf_pool) macro refuses to use the new custom memory pools:

LWIP_PBUF_MEMPOOL(PBUF_POOL, PBUF_POOL_SIZE,    PBUF_POOL_BUFSIZE,     "PBUF_POOL")

Hi Martin,

>The communication between them is made through the UART7 ports: PORTC4 -> RX(7), PORTC5 -> TX(7).

Makes no sense at all what you described above since UART2 uses different GPIO pins than the ones you stated above. How is the modem working at all using the same GPIO pins?

Perhaps you physically moved the modem to completely different GPIO pins on the X11 header? If not mistaken last I loaded (enet_lwip) UART0 uses GPIO A0/A1 and is the virtual CDM serial COM port for ICDI USB with a terminal emulator such as Putty. Otherwise if JP4/5 if moved into vertical position (1-3,2-4) UART2 of TM4C1294 is then the virtual COM port visible on ICDI USB.

Wouldn't you agree It really shouldn't matter to the web page what UART is being asserted as long as the UART FIFO can accept data and the GPIO pins physically connect to the modem?

From what you described fixed the problem it appears the modem was never on UIART7 to begin with.

Thanks for your time BP101, perhaps I don't remarked that the UART7 is not used anymore, I have cahnged it for the UART2: PORTA6 -> RX(2), PORTA7 -> TX(2) in order to use the function UartPrintf(); (function only available to the physic UART2 ports) that's why i said that perhaps I was sending bad data for the UART7.

Thanks for your time, Regards

MARTIN C!

Yes you did state UART7 not used anymore. That explanation makes no sense why it now works as it should have been working ok with UART7.

Switching the modem to UART2 Port A6,A7 should not have made any difference if UART7 was actually being configured.

Port C  due to the JTAG pins C0-C3 are all locked GPIO pins, seemingly GPIO port C4, C5 need be unlocked using mask key code ( |= 0x30). 

Perhaps you did not unlock the GPIO port C prior to configuring it as UART7? 

Hi Martin

Ok now understand you also discovered Tivaware (UARTStdioConfig) is not programmed for access to UART7. We, you and the world might expect UART7 for use with the EK-TM4C1294XL or TM4C1294NCPDT.

Typically the Tivaware code should inform us UART7 invalid by error in that SANITY test during the project build! I tend to assume anyone who writes code to restrict peripheral use might include a Sanity test.   

Good find Martin:

    //
    // Check the arguments.
    //
    ASSERT((ui32PortNum == 0) || (ui32PortNum == 1) ||
           (ui32PortNum == 2));

BP101 said:

Port C  due to the JTAG pins C0-C3 are all locked GPIO pins, seemingly GPIO port C4, C5 need be unlocked using mask key code ( |= 0x30). 

Perhaps you did not unlock the GPIO port C prior to configuring it as UART7? 

*** ***

My friend - Port "C" GPIO pins outside of PC0-PC3 require NO SUCH Unlocking!   Here - the MCU manual details:

Port "A" comes closest to your "seemingly" - but PA6 & PA7 escape - thus NO Port requires a complete Unlock!  We've (long) used "upper nibble" of Port C - never unlocking!

Devil in such detail - MCU manual provides much...

>seemingly GPIO port C4, C5 

Did use the word seemingly. Albeit long ago CB1 (seemingly) agreed port C unlock (may) be needed for COMP0(C0-/C1-) input assigned GPIO pins C4,C7. To answer BP101 post "Why PinMux tool can not program comparator pins?"

 Tiva Pinmux Tool output file wrote unlock C code for GPIO port C pins C4, C7. That unlock code led to belief the (entire) GPIO C port was indeed locked and Table 9-1 was incorrect. Appears was not alone in that belief to unlock the upper nibble GPIO port C pin [4:7].

However the Tivaware UARTStdioConfig Sanity ASSERT testing UART0-2 should have produced CCS compiler warnings in the Problems tab.

Why CCS missing warning lead to this post is interesting yet it revealed other Silent forum posters LWIP1.4.1 confirmed heap issues in memory pool. That is not good for yet again Silent Exosite IOT users that remain in time bomb payload crash out weeks or months online.

BP101 said:

Albeit long ago CB1 (seemingly) agreed port C unlock (may) be needed for COMP0(C0-/C1-) input assigned GPIO pins C4,C7.

I'd love to see that (long past) "agreement - I'm in doubt.   Much doubt!

It is only Port pins C0-C3 which are now (and have been) so encumbered!

Good luck.