TM4C1294KCPDT: multiple tasks on ethernet gives fault isr or watchdog reset

HI,

  What is your current stack size and heap size? Can you try to increase your stack size and heap size (if you are using dynamic memory)? Will it make a difference? Many of the times, a fault was tripped by the stack overflow. The fault exception probably take you to FaultISR() which is the default exception handler for hard fault defined in the startup_ccs.c file. The FaultISR() just spins in a while(1) loop if you didn't write your own routine. Since it is spinning in a while loop it will later trip your watchdog reset if you configure the watchdog in your application.

URVI SHAH said:

If I try to handle all tasks at a same time then device will either goes into fault isr or gives me watchdog interrupt.

Vendor's Charles nicely highlights, 'Stack and/or Heap Inadequacy' as the 'usual suspects.'       And indeed - that provides quick/eased, borderline painless 'fix.'

In the event that the issue persists - and in honor of your request for a 'systematic procedure' to resolve - may  I  suggest:

• Carefully/Systematically - Remove (just one) of your multiple tasks - and then rerun your program
• Never (almost never) will the first task 'removed' prove the 'issue's cause' - it is thus (almost) certain that your 'issue' remains
• Re-enable that task (initially removed) and remove another task - again observing if the 'issue' is resolved
• Repeat this, 'Selective Removal & Test/Observe' - until each/every one of the multiple tasks have been so exercised

The procedure described aims to determine the identity of  'one or perhaps even several' tasks - which 'cause your issue'      This method employs the 'Process of Elimination' - to systematically 'probe' for task failure(s).

There's an even faster method to implement the above:

• Break your tasks into 'reasonably' equal halves - and disable/remove, 'One of those Halves'
• Run the program so that the issue's presence is tested
• Should the issue not occur - repeat the test - but only after 'swapping' the 'Task Halves.'     (i.e. that task half which worked is now disabled - and the 'untested task half' is now tested.)

In this manner - the following analysis results:

• if both 'task halves' PASS (no faults) - then Charles 'Stack/Heap' suggestion rises (even) higher
• if one & only one 'task half' fails - the issue is  (likely)  contained w/in 'One of that half's task inventory'
• if both 'task halves' FAIL - the 'Stack/Heap' may again prove 'guilty'
• in the case of 1 or 2 'task half' failures - employ the earlier (above detailed) procedure - to determine the (likely) offending task(s)

it often proves helpful to 'rearrange the order' in which each task is called/sequenced - this enables the detection of  'Sequence Sensitivity'  which is (not) usually deemed a 'task fault.'     (there are further systematic methods to 'tease out' sensitivity impacts (should that prove an issue) - as well...)

Hello,

You might try modify lwiplib.c adding additional call timers for each protocol while(1) handler, add timers to lwipopts.h, same GPTM calls interrupt handler. The tiva129c_hal.c HAL may be suspect for DMA descriptor crashes setting dog to barking if Pbuf pool corrupts.

 Unrecoverable DMA I/O errors viewed as perpetual DMARIS RxBuffer full flags via CCS debug. Worst case scenario FBI gets involved check SYSCTL for fatal bus errors. Check NVIC register for bus error type Precise or Non-precise, indicates memory address valid or rouse (unknown).

Known fix!

#if NO_SYS
static void
lwIPServiceTimers(void)
{
    //
    // Service the 1st Eth_Client_1 host.
    //
#if HOST_TMR_INTERVAL1
    if((g_ui32LocalTimer - g_ui32HostTimer1) >= HOST_TMR_INTERVAL1)
    {
        g_ui32HostTimer1 = g_ui32LocalTimer;
        lwIPHostTimerHandler1();

    }
#endif
    //
    // Service the 2nd Eth_Client_2 host.
    //
#if HOST_TMR_INTERVAL2
    if((g_ui32LocalTimer - g_ui32HostTimer2) >= HOST_TMR_INTERVAL2) 
    {
        g_ui32HostTimer2 = g_ui32LocalTimer;
        lwIPHostTimerHandler2();


    }
#endif