my code is getting crash within few seconds after calling xQueueSendToBackFromISR

paulmurugan wrote on Friday, February 27, 2015:

Hello Together,

Problem: my code is getting crash within few seconds after my activation of timer input capture interrupt

I have used freeRTOS for freescale HCS12X series microcontroller and developed code for periodic tasks and for interrupt task (porting code taken from HCS12_HCS12X_CodeWarrior_OAF).
Interrupt been implemented with handler task support. Syncronization has been implmented via semaphore and queue concept. As of now i have
created three interrupts.

  1. RTI interrupt for Timer tick generation (RTI- Real Time iInterrupt)
  2. Timer over flow interrupt for my use. There is no semaphore and queue have been used inside this routine so portYIELD function is not used within the ISR.
  3. Timer input capture interrupt, used queue concept. It has a handler task to receive the queue and calling some function.

Actually my code is getting crash within few seconds after my activation of timer input capture interrupt(generated square wave using function generator with frequency about 1Hz to 2Khz). i follow the procedure given in freerTOs manual for implementing ISR and handler function. Perhaps i disable the handler funcion to stop receiving the queue data to know portYIELD would be the reason for crash. But still the problem exist.

I have posted my code below.

#define portYIELD() __asm( “swi” );

/* ISR routine */
__interrupt VectorNumber_Vtim1ch4 void ML_Timer1Ch4_ISR (void)

{

portBASE_TYPE pxHigherPriorityTaskWoken;
ML_Timer_ISRHandlerParam p_ISRarameter;
if( TIM1_TIOS_IOS4 == (Bool)0)
{
    parameter.timer = TIMER_1;
    parameter.channel = CHANNEL_4;
    parameter.timer_count = TIM1_TC4;
    parameter.overflow= timer1_Overflow[4];
    timer1_Overflow[4] = 0;
} 
else 
{
  /* Future use - Code for Output Compare */
}

TIM1_TFLG1|= 0x10;

xQueueSendToBackFromISR (ML_TIMER_CAPTURE_HANDLE, &parameter, &pxHigherPriorityTaskWoken);
/* Blocked task, waiting for this Queue has priority higher than the interrupted task */
if(pxHigherPriorityTaskWoken == pdTRUE) 
{
 portYIELD();
}

}

/* ISR hnadler task 3*/

static void ISRHandleQueueFunction (void pvParameters)
{
BaseType_t return_flag;
SL_ISRHandle_Config taskparameter;
/
Accessing task configuration through task parameters */
taskparameter = (SL_ISRHandle_Config )pvParameters;
for(;:wink:
{
/
Queue data receive from interrupt service routine */
return_flag = xQueueReceive(taskparameter->handle_name, &taskparameter;portMAX_DELAY);

/* Task calling */
(taskparameter->taskID)(queueBuffdata);

}
}

__interrupt VectorNumber_Vswi void vPortYield (void)
//void vPortYield (void)
{
portSAVE_CONTEXT();
vTaskSwitchContext();
portRESTORE_CONTEXT();
}

/* RTI interrupt for Tiemr tick generation */
__interrupt VectorNumber_Vrti void TimerTick_ISR (void)

{
#if configUSE_PREEMPTION == 1
{
/* A context switch might happen so save the context. /
portSAVE_CONTEXT();
PORTB_PB2=1;
/
Increment the tick … */
if( xTaskIncrementTick() != pdFALSE )
{
vTaskSwitchContext();
}

	CRGFLG_RTIF = (Bool)1;								   

	/* Restore the context of a task - which may be a different task
	to that interrupted. */
	PORTB_PB2=0;
	portRESTORE_CONTEXT();	
}
#else
{
	xTaskIncrementTick();
	CRGFLG_RTIF = (Bool)1;
}
#endif

}

Note:I have not used interrupt nesting in my project. configMAX_SYSCALL_INTERRUPT_PRIORITY is not avilable in my project.

rtel wrote on Friday, February 27, 2015:

Sorry, I am confused. Which architecture are you running this on? You mentioned an HSC12, which is a rather old port (although also a simple port so should be ok). If so, did you start with the demo in the FreeRTOS download and follow the instructions for that demo to create interrupts, etc.? There should be no need for you to be doing things like defining your own yield macros, they are already defined by the port layer.

Have you done things like turn on stack overflow checking, defining configASSERT(), etc.?

Regards.

paulmurugan wrote on Friday, February 27, 2015:

Hi,

I am using MC9S12XHY256 freescale microcontroller (HCS12X architecture). So the demo project is not fit for this HCS12X architecture. I have taken the micro controller porting code from the below link.

http://interactive.freertos.org/attachments/token/hdyi5fvvqwwocdq/?name=HCS12_HCS12X_CodeWarrior_OAF.zip

If the timer input capture interrupt is disabled (which has xQueueSendToBackFromISR function call), all the periodic tasks are running without any issues. Perhaps if i enable timer interrupt then the code is getting crash after a period of time.

Kindly let me know what could be cause of the issue. You can refer the code i have shared in my previous post.

Thanks

eldar123 wrote on Thursday, February 16, 2017:

Hi,
Did you find any solution to this? I’m trying to find a bug in some old software which looks very much like what you are describing. I am using MCS9S12XEQ512 running FreeRTOS 8.1.2 and the “CW/OAF” HCS12X port version. The task context switching works fine as long as there is no other IRQs. Once I enable other (timer) interrupts which don’t even call any FreeRTOS functions, the application crashes after a while at random places with smashed stack. Something seems to go wrong with the portSAVE_CONTEXT / vTaskSwitchContext / portRESTORE_CONTEXT when there are more pending interrupts waiting at the same time as a context switch (i.e. jumping to another ISR after context switch in vPortTickInterrupt). We are not using nested interrupts.

Thanks

eldar123 wrote on Wednesday, February 22, 2017:

Hi,
In my case, the solution was to add the “D/E/G/P/R PAGE Register is used” in CW/Compiler/Code Generation (HC12 Compiler 5.0.14.10203 options : “-CpDPAGE -CpGPAGE -CpEPAGE -CpPPAGE -CpRPAGE”) for all other interrupts. I didn’t find it documented anywhere, but the compiler will then add the assembly instructions to save/restore the mentioned registers when entring/exiting any ISR. Also I am using the portYIELD (swi) only, also from ISR’s (ISRs are using stack).
Many of the ISR are using xQueueSendToBackFromISR and other FreeRTOS calls. After this change, no more crashes have been recorded.
Regards