Program getting Reset while running after some time

Hello, I am working on enc28j60 ethernet, Sending Pings to the network (i have set both ipconfigUSE_DHCP_HOOK and ipconfigUSE_DHCP to 1, as i am using dynamic).
Program is running fine, I am getting Packets on Network but the problem is while running the program after some time( in seconds) It get reset and sometime instead of reset problem i am getting…
@ vApplicationStackOverflowHook

Below I have pasted the Tasks Creation

  if (xTaskCreate (vHandlingTask, "Reg2", 700, NULL, 2, &pxCreatedTaskISR))
    {
      vSendString ("handling task created\n\r");
    }

  if (xTaskCreate (prvRegTestTaskEntry3, "Reg3", 700, NULL, 1, NULL))
    {
      vSendString ("Task 3 Created \n\r");
    }

Here i am pasting the defination of tasks also…

void
vHandlingTask (void *pvParameters)
{
  uint32_t ulInterruptStatus = 0;

  for (; ; )
    {
      // Wait for notification from ISR (similar to binary semaphore)

      ulTaskNotifyTake(pdTRUE, portMAX_DELAY);

      taskENTER_CRITICAL();
      prvReceivePacket (NULL, 0);
      GPIO_read_pin(9);
      taskEXIT_CRITICAL();
    }
}

static void
prvRegTestTaskEntry3 (void *pvParameters)
{
  /*Although the regtest task is written in assembler, its entry point is
   written in C for convenience of checking the task parameter is being passed
   in correctly.*/

  xPingReplyQueue = xQueueCreate(10, sizeof(unsigned long));

  while (1)
    {
      //vSendPing ("192.168.0.1");              // for static(ipconfigUSE_DHCP=0)
      vSendPing ("10.176.18.104");              // for dynamic(ipconfigUSE_DHCP=1)

      vTaskDelay (100);

      /*The following line will only execute if the task parameter is found to
       be incorrect.  The check task will detect that the regtest loop counter is
       not being incremented and flag an error.*/
    }
  vTaskDelete ( NULL);
}

Below is external handler

/*  ISR */
void
EXTI2_IRQHandler (void)
{
  //enc28j60_bfc (EIE, EIE_INTIE); // mask enc28j60 interrupts (not using in vs code)
  // volatile uint8_t eir_flags = enc28j60_rcr (EIR);

  GPIO_write_pin (9, 0);

  volatile BaseType_t xHigherPriorityTaskWoken = pdFALSE;

  vTaskNotifyGiveFromISR(pxCreatedTaskISR, &xHigherPriorityTaskWoken);

  //xSemaphoreGiveFromISR(sem_done_reading, &xHigherPriorityTaskWoken);

  /* If xHigherPriorityTaskWoken is now set to pdTRUE then a context switch
   should be performed to ensure the interrupt returns directly to the highest
   priority task.  The macro used for this purpose is dependent on the port in
   use and may be called portEND_SWITCHING_ISR(). */
  if (xHigherPriorityTaskWoken == pdTRUE)
    {
      portYIELD_FROM_ISR(xHigherPriorityTaskWoken);
    }
}

In FreeRTOSConfig.h

#define configMINIMAL_STACK_SIZE ( ( uint32_t ) 300)

2 minor, unrelated hints:
BaseType_t xHigherPriorityTaskWoken = pdFALSE; is fine. The volatile specifier is not needed.
You can use portYIELD_FROM_ISR( xHigherPriorityTaskWoken ); without pre-checking xHigherPriorityTaskWoken. It’s checked internally anyway and in your case twice.

I think there is a problem in the code not shown.
If it’s just insufficient stack size, try to increase the stack of the task where the overflow hook is invoked.

1 Like

okay, I got your point But even after increasing the stack size of tasks it is not running continuously after some time Board is getting reset automatically.
BTW could you please tell me why we get TRAP, what is the reason behind it??

1 Like

When you get into the stack overflow hook, you can check the task name for which the stack overflow happened. Did you check that and increased the size of that task’s stack? Also, for testing set the configMINIMAL_STACK_SIZE to a higher value like 512.

The hardware you are using would have a way to determine the instruction that caused the trap. Which hardware are you using?

1 Like

First of all thank you for the reply and We have created our own microprocessor which is VEGA, So i am trying to interface enc28j60 Ethernet with it.
And yes I have increased the stack size of tasks also But if i increase too much then i’ll get vApplicationMallocFailedHook

As you told me to increase the configMINIMAL_STACK_SIZE, I did that too but still I am getting same result which i got earlier.
Right now my task stack size is

if (xTaskCreate (vHandlingTask, "Reg2", 800, NULL, 2, &pxCreatedTaskISR))

    {
      vSendString ("handling task created\n\r");
    }

  if (xTaskCreate (prvRegTestTaskEntry3, "Reg3", 800, NULL, 1, NULL))
    {
      vSendString ("Task 3 Created \n\r");
    }

and

#define configUSE_PREEMPTION				1
#define configUSE_TIME_SLICING				0
#define configUSE_IDLE_HOOK				1
#define configUSE_TICK_HOOK				0
#define configCPU_CLOCK_HZ				( ( uint32_t )  ( SYS_CLK_FREQ)/4000 )
#define configISR_STACK_SIZE_WORDS			2048


#define configTICK_RATE_HZ				( ( TickType_t ) 1000 )        //Change according to requirement.
#define configMAX_PRIORITIES				( 5 )
#define configMINIMAL_STACK_SIZE			( ( uint32_t ) 512) /* Can be as low as 60 but some of the demo tasks that use this constant require it to be higher. */
#define configTOTAL_HEAP_SIZE				( ( size_t ) ( 16 * 1024 ) )
#define configMAX_TASK_NAME_LEN				( 16 )

AND MY ANOTHER DOUBT IS should i need to change the value of #define configISR_STACK_SIZE_WORDS which is right now 2048.

This seems okay.

Do you still get stack overflow or just reset? Is it possible to figure out the source of reset?

I am trying to figure it out.

But sometimes I am getting stackoverflowhook too not just reset so I don"t know whether the problem is related with the stack overflow or RESET.

one more thing
#define ipconfigIP_TASK_STACK_SIZE_WORDS ( configMINIMAL_STACK_SIZE * 5 ) in FreeRTOSIPConfig.h

configMINIMAL_STACK_SIZE is 300 I have given right now. so, is it ok??

And after changes some setting when i try static method so it is more stable than dynamic.
(stable means Program run for atleast 15 min) changes which i have done for static is below.

#define configUSE_IDLE_HOOK 1
#define configUSE_TICK_HOOK 0
#define configCPU_CLOCK_HZ ( ( uint32_t ) ( SYS_CLK_FREQ)/4000 )
#define configISR_STACK_SIZE_WORDS 4096

#define configTICK_RATE_HZ ( ( TickType_t ) 1000 ) //Change according to requirement.
#define configMAX_PRIORITIES ( 5 )
#define configMINIMAL_STACK_SIZE ( ( uint32_t ) 512) /* Can be as low as 60 but some of the demo tasks that use this constant require it to be higher. */
#define configTOTAL_HEAP_SIZE ( ( size_t ) ( 32 * 1024 ) )
#define configMAX_TASK_NAME_LEN ( 16 )
#define configUSE_TRACE_FACILITY 1
#define configUSE_16_BIT_TICKS 0
#define configIDLE_SHOULD_YIELD 0
#define configUSE_MUTEXES 1
#define configQUEUE_REGISTRY_SIZE 8
#define configCHECK_FOR_STACK_OVERFLOW 1
#define configUSE_RECURSIVE_MUTEXES 1

And IP_TASK_STACK SIZE IS

#define ipconfigIP_TASK_STACK_SIZE_WORDS ( configMINIMAL_STACK_SIZE * 1)

but using this setting why i run this program in dynamic mode then I am getting problem, after few seconds either it is reset problem , TRAP or overflow (mostly i am facing RESET right now or TRAP).
Please share your views on this.

It is likely a stackoverflow leading to memory corruption.

Try defining to something more like 4096.

The easiest is to check the task name when you hit stackoverflow hook and increase the stack size for that task.

1 Like
void
vApplicationStackOverflowHook (TaskHandle_t pxTask, char *pcTaskName)
{
  (void) pcTaskName;
  (void) pxTask;

  printf("stack overflow %x %s\r\n", pxTask, (portCHAR *)pcTaskName);
  vSendString ("@ vApplicationStackOverflowHook\n\r");
  /* Run time stack overflow checking is performed if
   configCHECK_FOR_STACK_OVERFLOW is defined to 1 or 2.  This hook
   function is called if a stack overflow is detected. */
  taskDISABLE_INTERRUPTS();
//  __asm volatile( "ebreak" );
  for (;; )
    ;
}

IS it right way???

Yeah, I have did that too but the problem is right now vApplicationStackOverflowHook is not generating. RESET or TRAP issue continously occuring.

Yes, that seems right.

When you are in the trap, can you check the value of EPC to find out the address of the faulting instruction and then check the assembly at that address. This may give us some idea about what is causing the fault.

yeah i though about it too but when i search the function from where TRAP is printing in that function they have already printing EPC, cause values but in my case only TRAP is printing on OUTPUT, may be that TRAP is coming from boot loader i am not sure about it.

And yes one more thing which i would like to share.
if i connected my ethernet with my computer then it is more stable than when i connected it to my network.
what are your views on this??..is it possible that when connected to network due to more traffic problem is creating??

Are you saying that you are not able to locate the source code of TRAP handler? If yes, then it may be coming from boot loader. If EPC is getting printed, can you atleast check if it is in your code region and if yes, what line is at that address.

It may be one of the reason but It is hard to guess.

If it is coming from boot loader then Do you have any idea to resolve it??

No EPC is not printing.

If you have access to the code of the boot loader, you can try to debug it. If not, you need to reach out to the vendor.

okay

Anyway bro, I have got improvement in my code. as i told you earlier that may be heavy traffic is causing problem in my code so after enable filtering method in my Ethernet module, stability increase in my code. it is stuck after sometime but the duration of running code is increased.

whenever the code is running, on the output screen i am getting output like this:

hello
hello
hello
hello
stack overflow 0 �#&
@ vApplicationStackOverflowHook
hello
hello
hello
hello
hello
hello

‘hello’ means i am receiving the reply of ping so it should be printing continuously, in between you can see it is generating “stackoverflowhook” but it is unable to print the taskname. why it is showing like that(some random characters)??

/**************************************************************************************************/
void
vApplicationStackOverflowHook (TaskHandle_t pxTask, char *pcTaskName)
{
(void) pcTaskName;
(void) pxTask;

printf(“stack overflow %x %s\r\n”, pxTask, (portCHAR *)pcTaskName);
vSendString (“@ vApplicationStackOverflowHook\n\r”);

/* Run time stack overflow checking is performed if
configCHECK_FOR_STACK_OVERFLOW is defined to 1 or 2. This hook
function is called if a stack overflow is detected. */
taskDISABLE_INTERRUPTS();
// __asm volatile( “ebreak” );
for (;; )
;
}
/*****************************************************************************************************/
both tasks are having 1000 stack size, ISR stack size is 2048 and ip stack size is ( configMINIMAL_STACK_SIZE * 5), minimal stack size is 500.
and when i increase the all stack sizes and heap size then i am not getting this overflow hook but after few minutes program stuck.

I think increasing the stack size is the right thing to do here. If the print is not working, you can put a breakpoint in the stack overflow hook and examine the task name in the debugger. You need to debug the source of trap as we discussed before.

stack overflow 0 �#&

Note that the printed task handle is 0, but that should never be a correct task handle.

This means that something is corrupting memory.

That is a tough form of error to find

Does your MCU have something similar to ARM Cortex’s DWT? If yes, you can configure a break whenever a certain value (in your case 0) is written to a certain memory location (in your case that may be the current task handle). That feature is incredibly useful for debugging failures like the one you see.

I am confused with the task handle handle. I am porting freertos, and sometimes the pxCurrentTCBs points to ucHeap not stack. I just started with freertos, when does these happens?

A common root cause for that is corrupted linked lists (many FreeRTOS system structures are implemented as linked lists) due to incorrect serialization (misconfigured interrupt priorities or incorrect usage or non-usage or implementations of critical sections), another one is memory trampling over system data structures (eg stack overflows). The important thing to understand is that the symptoms may manifest themselves much much later after the root cause happened.

1 Like