• State Resolved
  • Locked Locked
  • Replies 5 replies
  • Answers 1 answer
  • Subscribers 30 subscribers
  • Views 6396 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 Debug (lwipopts.h) jumbles UART print messages & Incompatible #defines (cc.h)

Genatco
Guru 55913 points
Other Parts Discussed in Thread: TM4C1294NCPDT

Seems we didn't fully test the LWIP debug engine after writing the vendor supplied message return strings in:

TivaWare_C_Series-2.1.0.12573. The platform Diag/Assert error strings on first check appear to be merged into the ASSERT (msg) string. Later checking finds (stats.c) is preformatting the UART print STAT strings with NL/TAB.

1 - CCS compiler generates 100's of parsing warnings (unrecognized character escape sequence) when the UART print message strings are placed in (lwipopts.h) versus moving them to (cc.h). LWIP suggests the vendor should handle debug messages in (lwipopts.h) and they did. 

2 - CCS compiler warns of incompatible UART print message redefines ever LWIP Debug is enabled, that is unless the parent (#indef) are first commented out in (cc.h).

3 - When the LWIP Debug UART print message defines are moved from (lwipopts.h) into (cc.h) CCS compiler warnings are less than 5.   

4 - When LWIP hardware debug NETIF/TCP/UDP etc..  are enabled they seem to invoke only after 100's of compiler warnings are in the mix and incompatible (msg) defines exist.    Otherwise it seems to be pure luck LWIP debug UART prints TCP stack protocol messages at all. 

Below attempt to correct the missing NET_IF message string UART prints of the DEBUGF messages. Appears the event error message was omitted in the LWIP_PLATFORM_DIAG (msg) string. The TCP stack protocol debug messages are not printing second example below.

The LWIP_STATS print out most often yet end of the message string is always mangled leaving out the information that caused the DEBUGF error. Needless to say it is impossible to fully debug EMAC/PHY issues if the Vendor debug engine is broken.

May benefit all if we work together to make the LWIP_STATS messages actually report the entire message string. Please post any fixes in this area of the vendor debug message print. 

9.21.2015 **** Remove the ( \ ) after %s in UARTprintf will stop 100's of compiler warnings.

//*****************************************************************************
//
// ---------- Debugging options ----------
//
//*****************************************************************************
#ifdef DEBUG
#define U8_F "c"
#define S8_F "c"
#define X8_F "02x"
#define U16_F "u"
#define S16_F "d"
#define X16_F "x"
#define U32_F "u"
#define S32_F "d"
#define X32_F "x"
extern void UARTprintf(const char *pcString, ...);
#define LWIP_PLATFORM_DIAG(msg) UARTprintf msg
#define LWIP_PLATFORM_ASSERT(msg) \
    UARTprintf("ASSERT_FAIL at line %d of %s:\ %s\n", __LINE__, __FILE__, msg)
#define LWIP_DEBUG 1
#endif

#define LWIP_DBG_MIN_LEVEL              LWIP_DBG_LEVEL_ALL
//#define LWIP_DBG_MIN_LEVEL              LWIP_DBG_LEVEL_OFF //Compatability
//#define LWIP_DBG_MIN_LEVEL              LWIP_DBG_LEVEL_WARNING
//#define LWIP_DBG_MIN_LEVEL              LWIP_DBG_LEVEL_SERIOUS
//#define LWIP_DBG_MIN_LEVEL              LWIP_DBG_LEVEL_SEVERE

//#define LWIP_DBG_TYPES_ON               LWIP_DBG_ON
#define LWIP_DBG_TYPES_ON               (LWIP_DBG_ON, LWIP_DBG_TRACE|LWIP_DBG_STATE|LWIP_DBG_FRESH)

//#define ETHARP_DEBUG                    LWIP_DBG_OFF     // default is OFF
#define NETIF_DEBUG                     LWIP_DBG_ON


Seems (UDP_DEBUG == On)  has to be enabled order for the other protocol debugs to print messages & work.

tcp_slowtmr: no active pcbs
<< requests.c; SyncWithExosite(): Exosite_Write-Request >>
udp_connect: connected to 0.0.0.0,port 49153
udp_send
udp_send: added header in given pbuf 2000004c
udp_send: sending datagram of length 40
udp_send: UDP packet length 40
udp_send: UDP checksum 0xb781
udp_send: ip_output_if (,,,,IP_PROTO_UDP,)
ip_output_if: ti0
IP header:
+-------------------------------+
| 4 | 5 |  0x00 |        60     | (v, hl, tos, len)
+-------------------------------+
|        2      |000|       0   | (id, flags, offset)
+-------------------------------+
|  255  |   17  |    0x0000     | (ttl, proto, chksum)
+-------------------------------+
|   10  |    1  |   10  |   21  | (src)
+-------------------------------+
|  209  |   18  |   47  |   61  | (dest)
+-------------------------------+
netif->output()udp_connect: connected to 0.0.0.0,port 49153
udp_send
udp_send: added header in given pbuf 2000004c
udp_send: sending datagram of length 40
udp_send: UDP packet length 40
udp_send: UDP checksum 0xb781
udp_send: ip_output_if (,,,,IP_PROTO_UDP,)
ip_output_if: ti0
IP header:

 

  • 0
    Guru 55913 points

    Appears to be how (LWIP_PLATFORM_DIAG) invokes the message print engine in (lwipopts.h)

    9.21.2015 **** Remove the ( \ ) after %s in UARTprintf will stop 100's of compiler warnings.

    UARTprintf("ASSERT_FAIL at line %d of %s: %s\n", __LINE__, __FILE__, msg)

     

    LWIP 1.4.1: (debug.h)

    #ifdef LWIP_DEBUG
/** print debug message only if debug message type is enabled...
 *  AND is of correct type AND is at least LWIP_DBG_LEVEL
 */
#define LWIP_DEBUGF(debug, message) do { \
                               if ( \
                                   ((debug) & LWIP_DBG_ON) && \
                                   ((debug) & LWIP_DBG_TYPES_ON) && \
                                   ((s16_t)((debug) & LWIP_DBG_MASK_LEVEL) >= LWIP_DBG_MIN_LEVEL)) { \
                                 LWIP_PLATFORM_DIAG(message); \
                                 if ((debug) & LWIP_DBG_HALT) { \
                                   while(1); \
                                 } \
                               } \
                             } while(0)

#else  /* LWIP_DEBUG */
#define LWIP_DEBUGF(debug, message) 
#endif /* LWIP_DEBUG */
  • 0 in reply to Genatco
    Guru 55913 points
    Found a backward "( " in (tcp.c) was adding to the total number parsing warnings.

    Appears (stats.c) handles LWIP_STATS debug message strings for the UART print message in (lwipopts.h). So it is not necessary to assign LWIP_PLATFORM_DIAG(msg) with conditions prior to UART printing.

    There may be an formatting issue in (stats.c) as the print strings near the end messages become mangled.
  • 0
    TI__Guru**** 244400 points
    Hello BP101

    Thank you... I think we may need to have a call to clear up the LwIP Stack integration for the next TivaWare release....

    Regards
    Amit
  • 0 in reply to Amit Ashara
    Guru 55913 points

    Hi Omit,

    Part of the problem was (opt.h) has all Stats  enabled so debug was swamping the UART print buffer, not displaying half of the stats. Set them all to (0) no property constraints (opt.h) and only enable those you want in (lwipopts.h). Moved stats enable into (lwipopts.h) makes more sense to deal with that animal in his cage.

    Now we can selectively enable only those stats we wish to display or turn on/off stats by simply //DEBUG in (lwipopts.h). Still have 100's of compiler warnings more so when (MEMP_STATS) are enabled. Often can get warnings down to 2 after first cleaning and close CCS then reopen and compile. Weeks not hours dealing with LWIP beasty.

    Anyone wanting to improve troubleshooting add this code to (lwipopts.h) and set all every STAT to (0) in (opt.h). That mandates to remove all Word property assigned to individual switches in (opt.h).

    //*****************************************************************************
//
// ---------- Statistics options ----------
//
//*****************************************************************************
#define LWIP_STATS                      1   // No Print Stats == 0

#if LWIP_STATS

#define LWIP_STATS_DISPLAY              1
//#define LINK_STATS                      0
//#define ETHARP_STATS               (LWIP_ARP)
//#define IP_STATS                        1
//#define IPFRAG_STATS                    (IP_REASSEMBLY || IP_FRAG)
//#define ICMP_STATS                      1
//#define IGMP_STATS                      (LWIP_IGMP)
//#define UDP_STATS                       (LWIP_UDP)
#define TCP_STATS                       (LWIP_TCP)
#define MEM_STATS                       1
//#define MEMP_STATS                      1
//#define SYS_STATS                       1

#else

#define LWIP_STATS_DISPLAY              0
#define LINK_STATS                      0
#define ETHARP_STATS                    0
#define IP_STATS                        0
#define IPFRAG_STATS                    0
#define ICMP_STATS                      0
#define IGMP_STATS                      0
#define UDP_STATS                       0
#define TCP_STATS                       0
#define MEM_STATS                       0
#define MEMP_STATS                      0
#define SYS_STATS                       0

#endif /* LWIP_STATS */

  • 0 in reply to Amit Ashara
    Guru 55913 points

    Hi Amit,
    Recently added SS1 to existing & running ADC1: FIFO1 - 2 ANix channels for sensor inputs. Immediately following early after POR random bus faults with LWIP TCP connections to Exosite. Could not stop the minutes after POR bus faulting occurring during EMAC Tx/Rx TCP packets frames out the PHY. 
     
    Now have replaced the exoHAL blocking flags (HREGBITW) with single int16_t Variables. That alone immediately showed benefit in (TCP_TMR_INTERVAL 250ms). This tells me there are timing issue with LWIP1.4.1 and TM4C1294NCPDT.

    That macro's instruction times for pushing a flag variable on the stack seem to numerous for a simple flag push. The macro even involves a struct again all for a simple flag.

     Lightning Fast: int16_t g_sExoHALRxFlag;

    Turtle speed: HWREGBITW(&g_sExosite.ui32Flags, FLAG_RECEIVED) = 0;