How identify interrupted task from ISR?

fojtik wrote on Sunday, February 10, 2013:

I need to identify, which task has been interrupted.

Normally this functionality is not necessary, but in the protection fault handler it is very useful to know which task has been failed before restarting device. The failing task name could be recorded and reported after restart.

/** This function returns a current task name. */
const signed portCHAR *xCurrentTaskGetNameFromISR(void)
{
  if(pxCurrentTCB==NULL) return NULL;
  return pxCurrentTCB->pcTaskName;
}

I am not sure whether it is possible to suspend this task (if a task is not critical e.g. www server) and continue with normal operation.

fojtik wrote on Sunday, February 10, 2013:

Just to clarify - I have to patch every RTOS source code with this. pxCurrentTCB is not exported outside RTOS sources - or I do not know to identify a task other way.

rtel wrote on Sunday, February 10, 2013:

See the following API functions:

#if ( ( INCLUDE_xTaskGetCurrentTaskHandle == 1 ) || ( configUSE_MUTEXES == 1 ) )
  xTaskHandle xTaskGetCurrentTaskHandle( void )
  {
  xTaskHandle xReturn;
    /* A critical section is not required as this is not called from
    an interrupt and the current TCB will always be the same for any
    individual execution thread. */
    xReturn = pxCurrentTCB;
    return xReturn;
  }
#endif
#if ( INCLUDE_pcTaskGetTaskName == 1 )
  signed char *pcTaskGetTaskName( xTaskHandle xTaskToQuery )
  {
  tskTCB *pxTCB;
    /* If null is passed in here then the name of the calling task is being queried. */
    pxTCB = prvGetTCBFromHandle( xTaskToQuery );
    configASSERT( pxTCB );
    return &( pxTCB->pcTaskName[ 0 ] );
  }
#endif /* INCLUDE_pcTaskGetTaskName */

Regards.

rtel wrote on Sunday, February 10, 2013:

Relevant web pages:

http://www.freertos.org/a00021.html#xTaskGetCurrentTaskHandle
http://www.freertos.org/a00021.html#pcTaskGetTaskName

Regards.

fojtik wrote on Sunday, February 10, 2013:

Thank you very much, but this does not fully work.

Yes, I obtain “xTaskHandle”, but the task name cannot be extracted from it. Struct “tskTaskControlBlock” is declared in task.c and does not extend its scope.

When I need task name, I still must patch FreeRTOS same way. The task handle is not very userfull during task crash and preparation to reboot. (Only to create crash image.)

fojtik wrote on Sunday, February 10, 2013:

sorry, i must to upgrade, version 5.4.2 does not contain"
      signed char * pcTaskGetTaskName( xTaskHandle xTaskToQuery );

joshuanapoli wrote on Monday, February 11, 2013:

fojtik,

You’re going down the same path that I did a few months ago. If you have a reusable fault handler, it’d be great if you could post it somewhere. I’m sure that there is a lot of duplicated effort among FreeRTOS users in the development of  exception handlers.

davedoors wrote on Monday, February 11, 2013:

Not sure which MCU you are using but have you seen this http://www.freertos.org/Debugging-Hard-Faults-On-Cortex-M-Microcontrollers.html

fojtik wrote on Monday, February 11, 2013:

I has been catching all of cortex M3 faults:     UsageFault_Handler()   BusFault_Handler()   MemMang_Handler()    HardFault_Handler()

All of them are normally referenced from IRQ table:
;******************************************************************************
; The vector table.
;******************************************************************************
        EXPORT  __Vectors
__Vectors
        DCD     StackMem + Stack            ; Top of Stack
        DCD     Reset_Handler               ; Reset Handler
        DCD     NmiSR                       ; NMI Handler
        DCD     HardFault     ; Hard Fault Handler
        DCD     DataAbort     ; MPU Fault Handler
        DCD     PrefetchAbort     ; Bus Fault Handler
        DCD     InstructionAbort     ; Usage Fault Handler

They are normal C functions. I have obtained here name of faulty task add name of fault and push it to external serial RAM (proprietary solution). After reboot the SRAM is read and fault is properly logged and reported. The fault are very rare, but it is very valuable to know which task has been crashed.