Send queue from one ISR works, not the other

groger57 wrote on Thursday, February 01, 2018:


I have an interrupt handler for a USART that uses the call “xQueueSendFromISR” that works with no issues. I would also like to use the same call from another interrupt (a timer), and I have set it up and using it exactly the same way. When it needs to execute, it causes the system to crash/boot.

Any suggestions as to why this is happening?


rtel wrote on Thursday, February 01, 2018:

Is it writing to the same queue? Can you please post the code.

groger57 wrote on Thursday, February 01, 2018:

Interrupt code below. Yes, it is writing to the same queue. I can post the handler too…let me know, thanks.

void TIM7_IRQHandler(void)
long lHigherPriorityTaskWoken = pdFALSE;

if( TIM_GetITStatus(TIM7, TIM_IT_Update) ) 
    /* Clear TIM7 Capture compare interrupt pending bit */
    TIM_ClearITPendingBit(TIM7, TIM_IT_Update);

    deltaAckTime = ( xTaskGetTickCount() - runData.checkForACK );                          
    //runData.checkForACK is set to xTaskGetTickCount() when mssg is sent
    //if deltaAckTime exceeds 70ms, it gets cleared.        
    if( runData.checkForACK ) //if active
        // ack received is handled in usart6 handler, and will 
        // zero out runData.checkForACK if received
        if( deltaAckTime == 70 )
            runData.checkForACK = 0;
            runData.gotACK = false;
            scMssgIn.SC.cmdCode = ACK_FAIL;
            scMssgIn.SC.type = SYS;
            xQueueSendFromISR( TxRxReceiveQueue, (void*)&scMssgIn.SC, &lHigherPriorityTaskWoken );         

} //end: if( TIM_GetITS....

portEND_SWITCHING_ISR( lHigherPriorityTaskWoken );        


rtel wrote on Friday, February 02, 2018:

I see you are calling xTaskGetTickCount() from an ISR. FreeRTOS has a
rule of thumb that says not to call any API functions that do not end in
FromISR from an interrupt. In this case whether that matters or not
depends on the architecture - if you are running this on a Cortex-M3
then you are ok.

Other than that nothing is obviously wrong, but some thoughts.

Is the other interrupt also using scMssgIn? If the interrupts nest then
that could potentially cause an issue.

I note you care clearing the pending bit first - is it possible that the
interrupt is being re-entered before the function has executed (causing
a kind of recursion)?

Have you ensured the priority of the interrupt is at or below whatever
configMAX_SYSCALL_INTERRUPT_PRIORITY is set at? A good way of checking
this is to use a recent version of FreeRTOS, ideally V10.0.1, as the
more recent the version the more assert()s the code contains to trap
incorrect priority assignments…of course assuming configASSERT() is
defined to something that lets you know it has been called. V10.0.1 I
think covers all cases.

If this is an STM32, have you called NVIC_PriorityGroupConfig(
NVIC_PriorityGroup_4 ); as described here:

groger57 wrote on Friday, February 02, 2018:

Ok, thanks for the help. I’m using an STM32F4, so for some reason the call to xTaskGetTickCountFromISR() stops the program, where xTaskGetTickCount() works OK. Also, I’ve used it in other programs and never had an issue (doesn’t mean I eventually won’t)
Yes, I do have NVIC_PriorityGroupConfig set to 4, as the USART6 setup did this, but still do so in every setup as a matter of routine.
Moving the call to clear the interrupt did not help. The only thing left I can think of is the nesting with regards to the data structure. I will check into it.

rtel wrote on Friday, February 02, 2018:

Can you step through in the debugger to see what happens?