unable to use TASK_NOTIFICATIONS from ISR and configuration of FreeRTOS on Cyclone V.

ssin wrote on Tuesday, June 12, 2018:

I am trying to configure FreeRTOS(V10.0.1)to run on ARM Cortex-A9( on cyclone V’s processor 0 ) and using Mentor toolchain’ arm-altera-eabi-gcc to compile/link my code.

Followed most of the step as defined at and referred to demo code for Cyclone V :
https://www.freertos.org/Using-FreeRTOS-on-Cortex-A-proprietary-interrupt-controller.html

I want to setup an interrupt to run every few ms (say 1ms) and to release sempahore that blocks the task from ISR servicing this interrupt.
Want to use task notificaion API to synchronise this ISR and a task. I have set the interrupts priority at (portLOWEST_USABLE_INTERRUPT_PRIORITY << portPRIORITY_SHIFT) (tried with slightly higher priority also)

I have defined ALT_INT_PROVISION_VECTOR_SUPPORT in my project so to disable defination of void attribute ((interrupt)) __cs3_isr_irq(void) in alt_interrupt.c and defined a handler like:

void attribute ((interrupt)) __cs3_isr_irq(void)
{
FreeRTOS_IRQ_Handler();
}

and defined FreeRTOS_IRQ_Handler in FreeRTOSConfig.h as void FreeRTOS_IRQ_Handler ();

Similarly I have defined :
void attribute ((interrupt)) __cs3_isr_swi (void)
{
FreeRTOS_SWI_Handler();
}

I am facing 2 problems:

i) Moment I enable FreeRTOS_IRQ_Handler using above approach, I see software abort and looping in _cs3_isr_dabort. If I step through, software it does not abort(though task does not releases, see point ii below), but if I press F8 (on DS-5) software immediately goes in abort. Used vApplicationIRQHandler as in the demo project.

ii) The reason I want use portASM.S implementation was I was unable to release the semaphore in the task, it is always stuck in ulTaskNotifyTake(). I cannot see any defination of configKERNEL_INTERRUPT_PRIORITY in the demo supplied, so I have also not defined it. (Even setting it to 255 did not help). I tried binarys semphore (xSemaphoreGiveFromISR/ xSemaphoreTake), but with same result. Saw somewhere it is deprecated so moved to Task notificaion approach.

iii) Also timeout mechansim of ulTaskNotifyTake does not seems to work, though timertick/ timer1 are enabled.

iv)If I don’t modify my software to use portASM.s’s FreeRTOS_IRQ_Handler and use the one defined in Altera’s code software does not abort, but I cannot release the task from sempahore.

What is that I have missed or doing wrong ? Any help will be of great help.

Following is snapshot of ISR code:

/* At this point xTaskToNotify should not be NULL as a transmission was
in progress. */
configASSERT( xTaskToNotify != NULL );

 BaseType_t xHigherPriorityTaskWoken;

/* The xHigherPriorityTaskWoken parameter must be initialized to pdFALSE as
 * it will get set to pdTRUE inside the interrupt safe API function if a
 * context switch is required. */
 xHigherPriorityTaskWoken = pdFALSE;



/* 'Give' the semaphore to unblock the task, passing in the address of xHigherPriorityTaskWoken
 *  as the interrupt safe API function's  pxHigherPriorityTaskWoken parameter. */
 
 /* Notify the task that the transmission is complete. */
 vTaskNotifyGiveFromISR( xTaskToNotify, &xHigherPriorityTaskWoken );


 portYIELD_FROM_ISR( xHigherPriorityTaskWoken );


and following of the task:

uint32_t test_count = 0;
void vTask1( void *pvParameters ) {

 /* As per most tasks, this task is implemented within an infinite loop. */

uint32_t ulNotificationValue = 1;
const TickType_t xMaxBlockTime = pdMS_TO_TICKS(200);

configASSERT( xTaskToNotify == NULL );
xTaskToNotify = xTaskGetCurrentTaskHandle();

ALT_STATUS_CODE status = alt_int_dist_pending_clear(72);
status = alt_int_dist_enable(72);

 for( ;; )
 {
	ulNotificationValue = ulTaskNotifyTake( pdTRUE,
	                                             xMaxBlockTime );

	 if( ulNotificationValue == 1 )
	 {
	        /* The transmission ended as expected. */
		 ALT_PRINTF( "Handler task - Processing event .\r\n" );
	 }
	 else
	 {
	       /* The call to ulTaskNotifyTake() timed out. */
		 ALT_PRINTF( "Handler task - Processing event timeout.\r\n" );
	 }

	 test_count++;


 }

}

rtel wrote on Wednesday, June 13, 2018:

I suggest starting with the most basic setup, then build from there. A
good first place to start would be to disable the tick interrupt
(basically never start the tick in the first place), have a single task
that does nothing but increment a number then call taskYIELD(). That
will check the yield mechanism from a task - the task should basically
just increment the number then yield to itself - that is go through the
context switch interrupt but just select itself again. To do that make
sure the timer task is not started (configUSE_TIMERS is set to 0), and
that the single task has a priority greater than the idle priority -
that way you are ensured it will always be the task selected to run.

If that works then set configIDLE_SHOULD_YIELD to 1 and lower the
priority of the single task you created to 0. Now when you run it the
idle task and your single task should just repeatedly yield to each other.

Once that is working you can introduce the tick interrupt and have your
single task call vTaskDelay( x ); instead of taskYIELD(). That will
test that the tick interrupt is executing correctly, etc and so on until
you build up to the yielding from an interrupt scenario you describe.
Hopefully you will find the err along the way before you get to the end
step.

ssin wrote on Wednesday, June 13, 2018:

Thanks Richard for quick reply. I have tried as you have suggested, just running 1 task with taskYIED() .(configUSE_TIMERS , INCLUDE_xTimerPendFunctionCall and onfigIDLE_SHOULD_YIELD all set to 0 and commented out all the lines in vConfigureTickInterrupt)
Created a task like:
xTaskCreate( vTask1, “test”, 1000, NULL, 1, NULL );
After vTaskStartScheduler() , vTask1 runs . But on second call of taskYIED() it goes all over.
Feel some thing wrong from return of FreeRTOS_SWI_Handler().
Any thoughts on what can be going wrong ?

snapshot of swi handler:
void attribute ((interrupt)) __cs3_isr_swi (void)
{
FreeRTOS_SWI_Handler();
}

that calls portASM.S ( I have not modified any code in this file).
FreeRTOS_SWI_Handler:
/* Save the context of the current task and select a new task to run. */
portSAVE_CONTEXT
LDR R0, vTaskSwitchContextConst
BLX R0
portRESTORE_CONTEXT

ssin wrote on Wednesday, June 13, 2018:

Thanks Richard for quick reply. I have tried as you have suggested, just running 1 task with taskYIELD() .(configUSE_TIMERS , INCLUDE_xTimerPendFunctionCall and onfigIDLE_SHOULD_YIELD all set to 0 and commented out all the lines in vConfigureTickInterrupt)
Created a task like:
xTaskCreate( vTask1, “test”, 1000, NULL, 1, NULL );
After vTaskStartScheduler() , vTask1 runs . But on second call of taskYIELD() it goes all over.
Feel some thing wrong from return of FreeRTOS_SWI_Handler().
Any thoughts on what can be going wrong ?

snapshot of swi handler:
void attribute ((interrupt)) __cs3_isr_swi (void)
{
FreeRTOS_SWI_Handler();
}

that calls portASM.S ( I have not modified any code in this file).
FreeRTOS_SWI_Handler:
/* Save the context of the current task and select a new task to run. */
portSAVE_CONTEXT
LDR R0, vTaskSwitchContextConst
BLX R0
portRESTORE_CONTEXT

edwards3 wrote on Wednesday, June 13, 2018:

Can you copy the interrupt functions in the Cyclone example in the download https://www.freertos.org/RTOS_Altera_SoC_ARM_Cortex-A9.html

ssin wrote on Wednesday, June 13, 2018:

Thanks for quick reply Edwards.
In demo it is done in linker setting --defsym=cs3_isr_swi=FreeRTOS_SWI_Handler, need to find equivalent setting for Mentor toolchain’ arm-altera-eabi-gcc . --defsym is not recoginised by this toolchain.

ssin wrote on Wednesday, June 13, 2018:

Thanks for quick reply Edwards.
In demo it is done in linker setting --defsym=cs3_isr_swi=FreeRTOS_SWI_Handler, need to find equivalent setting for Mentor toolchain’ arm-altera-eabi-gcc . --defsym is not recoginised by this toolchain.

ssin wrote on Wednesday, June 13, 2018:

Setting in xlinker option as --defsym=cs3_isr_swi=FreeRTOS_SWI_Handler solved the problem. I can test one task as richard had suggested. Will test remaining and update. Thanks once again.

ssin wrote on Thursday, June 14, 2018:

All options suggested by Richard works. Also task notification from ISR works fine.