Keil RTX Task, FIQ & SW IRQ Interraction

Is this what you mean?

// DO NOT CALL THIS FUNCTION FROM PROGRAM CONTEXT - ONLY FROM FIRMWARE INTERRUPT CONTEXT !!!
void report_event_to_application(logical_id a_logical_id, int32u a_signal)
{
        task_info_t *lp_task_info = g_task_info ;
        int32u           l_index = NUMBER_OF_APPLICATION_USER_TASKS - 1 ;

        do
        {
                if (lp_task_info->logical_id == a_logical_id)
                {
                        isr_evt_set(a_signal, lp_task_info->id) ;  // must not be invoked from program content - only interrupt mode

                        break ;
                }

                ++lp_task_info ;
        }
        while ( (l_index--) > 0 ) ;
}

Is this what you mean?

// DO NOT CALL THIS FUNCTION FROM PROGRAM CONTEXT - ONLY FROM FIRMWARE INTERRUPT CONTEXT !!!
void report_event_to_application(logical_id a_logical_id, int32u a_signal)
{
        task_info_t *lp_task_info = g_task_info ;
        int32u           l_index = NUMBER_OF_APPLICATION_USER_TASKS - 1 ;

        do
        {
                if (lp_task_info->logical_id == a_logical_id)
                {
                        isr_evt_set(a_signal, lp_task_info->id) ;  // must not be invoked from program content - only interrupt mode

                        break ;
                }

                ++lp_task_info ;
        }
        while ( (l_index--) > 0 ) ;
}

Thank you for your response!

I thought isr_evt_set() could not called from an FIQ interrupt.

I tried it - with no success.
I single stepped through the interrupt and interrupt calls the event.
However, the RTX task that is waiting on the event never sees the event being signaled.

I guess you better ask Keil support or consult the RTX manual for your target. I don't know your chip (yet).

ARM Cortex-M3 (ST STM32)
According to the > RL-RTX > Theory of Operation > Interrupt Functions
-You cannot call the isr_ library functions from the FIQ interrupt function.
www.keil.com/.../rlarm_ar_inter_funct.htm

With this in mind, I could have a task pole for a bit

/* global bit that is poled for completion */
volatile BIT bRcvdMsg = __FALSE;

void USART1_IRQHandler(void)
{
    /* do some message checking here and if
    ** ok - then inform the task by setting a bit */
    bRcvdMsg = __TRUE;
}

__task void taskUSARTPollingTask( void )
{
    for(;;)
    {

        /* Just wait for a complete message to be received to inform
        **              the RS232 Handler Task */

        if(bRcvdMsg == __TRUE)
            /* Inform the RS232 Handler Task */
            isr_evt_set ( EM_DSP_USART_RCVD , g_taskCLI);

        os_dly_wait (20);
    }
}

--- OR ---

May be use SVC Functions or SWI Functions to map to the interrupt handler? Then use that to trigger the task. I haven't really seen this done in a task where they were using the RTX (at least not for the IC I am using). Any ideas?

Sorry - In the previous message, please replace
isr_evt_set() with
os_evt_set()

if(bRcvdMsg == __TRUE)
            /* Inform the RS232 Handler Task */
            isr_evt_set ( EM_DSP_USART_RCVD , g_taskCLI);

here you are trying to use the isr_evt_set function from user mode. that won't work.
why do you need a FIQ? can't you put up with a high priority IRQ?

Oops, you corrected yourself already. But my second comment stands: why not IRQ?

What about:

1 - FIQ does it's processing and detects 'completion'
2 - On completion, FIQ triggers a software generated IRQ
3 - IRQ does nothing except call isr_evt_set

I'm not familiar with your processor, but I have done this very same sequence successfully on an STR9.

There is no FIQ in Cortex-M, so there is no such problem. The core peripheral NVIC is used to generate exceptions. It is safe to use isr_xxx functions from the exception handlers.

Thank you for all the responses!!
(Sorry for the long wait - I have been on vacation)

Good news, the problem is fixed.

With all the comments, I focused on the code again and realized the functionality I was performing inside the interrupt was causing the problem. Not the isr function call from the IRQ.

Thanks again for all your help!!