Queu Send from ISR...Doesn't !

groger57 wrote on Thursday, December 31, 2015:

Hello:
Actually 2 questions here:

1 - The Queue handle has to get from one source file/function to the source file for the ISR. Is the best way to do this through an extern declaration?
in MAIN: QueueHandle_t isrQueue;
in ISR file: extern QueueHandle_t isrQueue;

2 - The queue task for receive does not seem to be detecting the send update. Here’s the declarations:
void QueueRxFunction( void *pvParameters );
QueueHandle_t isrQueue;
TaskHandle_t xQueueTask = NULL;
define rxQueue_RATE ( portMAX_DELAY )

isrQueue = xQueueCreate( 1, sizeof(uint8_t) );
xTaskCreate( QueueRxFunction, “rxDataQueue”, 140, NULL, 2, (TaskHandle_t)xQueueTask );

Function in MAIN:
void QueueRxFunction( void *pvParameters )
{
uint8_t rxValue = 0;
portBASE_TYPE xStatus;

for(;;)
{
    if( uxQueueMessagesWaiting( isrQueue ) != 0 )
    {
          //printf("Queue should be empty\n");
    }

    xStatus = xQueueReceive( isrQueue, &rxValue, rxQueue_RATE );        
    
    if( xStatus == pdPASS )
    {
        printf("Rcvd message from ISR %i\n", rxValue);
    }
}

}

Function in ISR:
void TIM6_DAC_IRQHandler(void)
{
long xHigherPriorityTaskWoken = pdFALSE;

if( TIM_GetITStatus(TIM6, TIM_IT_Update) ) 
{
.
.
.
   uint8_t flag = TRUE;
   xQueueSendFromISR(isrQueue, &flag, &xHigherPriorityTaskWoken);
   portEND_SWITCHING_ISR( xHigherPriorityTaskWoken );
}

Thank you for any help on this…(hoping eveyone at the FreeRTOS Support forum has a safe and excellent 2016!)

groger57 wrote on Thursday, December 31, 2015:

Hi,
I found one (large) silly error that I think I have fixed. The queue task:

void QueueRxFunction( void *pvParameters )
{
uint8_t rxValue = 0;
BaseType_t xStatus;
BaseType_t xTaskWokenByReceive = pdFALSE;

for(;;)
{
    if( uxQueueMessagesWaiting( isrQueue ) != 0 )
    {
          //printf("Queue should be empty\n");
    }
 
    xStatus = xQueueReceiveFromISR( isrQueue, (void*)&rxValue, &xTaskWokenByReceive );        
    
    if( xStatus == pdPASS )
    {
        printf("Rcvd message from ISR %i\n", rxValue);
    }
}

}

However, it’s not yet functioning - still never reaches the “xQueueReceiveFromISR” line.

Thanks,
Gary

groger57 wrote on Thursday, December 31, 2015:

Couple of other things that might be of interest:

The interrupt being set up and used is a timer driven interrupt to trigger an ADC read (STM32)

I have #define configLIBRARY_KERNEL_INTERRUPT_PRIORITY 15
NVIC_InitStructure.NVIC_IRQChannelPreemptionPriority = configLIBRARY_KERNEL_INTERRUPT_PRIORITY

In main I call NVIC_PriorityGroupConfig( NVIC_PriorityGroup_4 ); before the scheduler launch.

The code gets to line 602 in port.c (FreeRTOS 8.2.0)
configASSERT( ucCurrentPriority >= ucMaxSysCallPriority );

And stays there. Why would it do this when the interrupt is set up for a priority of 15, which is lower than the maximum of 0 ?

Thanks…

richard_damon wrote on Thursday, December 31, 2015:

The FromISR functions should only be used IN an ISR, and those shouldn’t have for(;:wink: loops.

Tasks getting data from a queue that was put in within an ISR don’t use FromISR routines, but the normal xQueueReceive function.

groger57 wrote on Thursday, December 31, 2015:

In my ISR I use nothing but:
xQueueSendFromISR(isrQueue, &flag, &xHigherPriorityTaskWoken);
portEND_SWITCHING_ISR( xHigherPriorityTaskWoken );

As you suggested, I changed my code to use a regular receive queue and it’s still stopped at 602 in port.c

something I don’t understand is at the beginning of my program I print out the value of
configMAX_SYSCALL_INTERRUPT_PRIORITY and it prints out (decimal) 80

Does that mean the priority of my timer interrupt must be at least 81 for the ISR to function correctly with the queue?

groger57 wrote on Thursday, December 31, 2015:

Also, the value of ulCurrentInterrupt in port .c is 0, which makes no sense!
In the Timer interrupt setup, I have this:
/ #define configLIBRARY_KERNEL_INTERRUPT_PRIORITY (14)
NVIC_InitStructure.NVIC_IRQChannel = TIM6_DAC_IRQn;
NVIC_InitStructure.NVIC_IRQChannelPreemptionPriority = configLIBRARY_KERNEL_INTERRUPT_PRIORITY;
NVIC_InitStructure.NVIC_IRQChannelSubPriority = 0;
NVIC_InitStructure.NVIC_IRQChannelCmd = ENABLE;
NVIC_Init(&NVIC_InitStructure);

No matter what the #define is, the value of ulCurrentInterrupt is always 0.

What could be wrong?

rtel wrote on Thursday, December 31, 2015:

I can have a proper look at this tomorrow (it’s nearly 11pm here) but first off, do you have configASSERT() defined? Assuming you are using a recent version of FreeRTOS that will catch most interrupt misconfiguration issues.

groger57 wrote on Thursday, December 31, 2015:

yes, I have it defined to:
define configASSERT( x ) if( ( x ) == 0 ) { taskDISABLE_INTERRUPTS(); for( ;; ); }

ok, thanks, I appreciate your assistance when you can get back to me. hope the rest of your evening is uninterrupted (no pun intended)
Gary

rtel wrote on Friday, January 01, 2016:

1 - The Queue handle has to get from one source file/function to the source file
for the ISR. Is the best way to do this through an extern declaration?
in MAIN: QueueHandle_t isrQueue;
in ISR file: extern QueueHandle_t isrQueue;

That work work fine.

The code gets to line 602 in port.c (FreeRTOS 8.2.0)
configASSERT( ucCurrentPriority >= ucMaxSysCallPriority );
And stays there. Why would it do this when the interrupt is set up for a
priority of 15, which is lower than the maximum of 0 ?

In which case the interrupt priority is not valid, and you are never writing to the queue.

something I don’t understand is at the beginning of my program I print out the value of
configMAX_SYSCALL_INTERRUPT_PRIORITY and it prints out (decimal) 80

80 is the priority shifted up into the most significant bits of the byte. See the Cortex-M hardware documentation and RTOS for ARM Cortex-M (that link is at the top of the "my application does not run, what could be wrong) FAQ page, which is always the first place to start).

Does that mean the priority of my timer interrupt must be at least 81 for the ISR to
function correctly with the queue?

That would depend on the library you were using the set the interrupt priority. If you are using the CMSIS libraries, then no, the priority you set would have to be the unshifted value. See the link above.

Also, the value of ulCurrentInterrupt in port .c is 0, which makes no sense!

I think index 0 is the stack start address - that doesn’t seem to make sense.

In any case, I think the reason your queue is not receiving is because, do to the assert() catching the invalid interrupt priority, nothing is actually being sent to it.

Regards.

groger57 wrote on Friday, January 01, 2016:

Hi RTE:
Now functioning! Problem - I took the suggestion on your page literally with respect to placing this “before” the scheduler launch:
NVIC_PriorityGroupConfig( NVIC_PriorityGroup_4 );

After placing it in the TImer 6 configuration, and before the call to
NVIC_Init(&NVIC_InitStructure);

Moving it there fixed it…the details will get you every time…
Thanks for taking the time to look at this!