• State Not Answered
  • Locked Locked
  • Replies 5 replies
  • Subscribers 15 subscribers
  • Views 2672 views
  • Users 0 members are here
Options
Related
How was your experience today?
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

RTX - inner workings of event queue

Trevor Hey

Hi,

I recently had problems with events (RTX isr events) resulting in the OS_ERR_FIFO_OVF error in os_error(). This prompted me to understand more about this mechanism. I will explain what I know and what I dont know, any input would be appreciated.

When isr_evt_set() is called, it seems that 2 entries are placed in the array os_fifo[]. The first I am guessing is the task control block for the task that must get the event and the second is the event ID. The size of this queue is set in RTX_Conf_xx.c as variable OS_FIFOSZ.

What I dont know:
1. How to flush this queue?
2. Does os_evt_wait..() remove an event from the queue? How? I cant see that to be true
3. How can one check how full the queue is.
4. Does os_evt_clr() clear one event (which one) or all events with the specified flags.

It's a pity the Keil/ARM don't make this information available

Parents
  • 0

    Hello Trevor,

    A neat feature of Cortex-M device is the low interrupt latency.
    A neat feature of the CMSIS-RTOS RTX is how fast it handles interrupts - it will not get in the way of the next interrupt.

    But the interrupt still may need to talk to the RTOS, e.g. the interrupt calls osMessagePut(), and the next interrupt calls osMailPut().

    So rather than run the complete osMessagePut() function, and potentially delay the next interrupt, the Kernel stores the bare minimum of data onto the FIFO Queue, and processes it later, when there are no pending interrupts.

    Some programmers take advantage of this by turning a large interrupt handler function into a high priority thread, and signal that thread when the interrupt occurs. This reduces nesting headaches, etc.

    If your FIFO queue is overflowing... troubleshoot your interrupt behavior.

    **The newer version of the Keil Debugger has an enhanced RTOS event window - you can see the threads and the interrupts all at once.

    www.keil.com/.../uv4_db_dbg_event_viewer.htm

    When you program errors, it should be stuck in RTX_Conf_CM.c in the function os_error() with the error code OS_ERROR_FIFO_OVF.

    You can open the event viewer and see the combination of interrupts that caused the issue. Typically this is some sort of nested interrupt issue.

    You could
    -Turn long Interrupt handlers into high priority threads
    -Use BASEMASK to mask out low importance interrupts
    -Change the priorities of the interurpts
    -Increase the FIFO size in the RTX_Conf_CM.c file

    When diagnosing interrupts,

    These windows may also be useful

    **The trace exceptions window (see the minimum, max time for a exception to enter, exit and run - useful to see if there are nesting issues):
    www.keil.com/.../ulink2_trace_exception.htm

    **Nested Vector Interrupt Controller - turn off and on exceptions:
    http://www.keil.com/support/man/docs/gsac/gsac_nvic.htm

    These windows need to have data tracing setup for the debugger:
    http://www.keil.com/support/man/docs/ulink2/ulink2_ctx_trace.htm

Reply
  • 0

    Hello Trevor,

    A neat feature of Cortex-M device is the low interrupt latency.
    A neat feature of the CMSIS-RTOS RTX is how fast it handles interrupts - it will not get in the way of the next interrupt.

    But the interrupt still may need to talk to the RTOS, e.g. the interrupt calls osMessagePut(), and the next interrupt calls osMailPut().

    So rather than run the complete osMessagePut() function, and potentially delay the next interrupt, the Kernel stores the bare minimum of data onto the FIFO Queue, and processes it later, when there are no pending interrupts.

    Some programmers take advantage of this by turning a large interrupt handler function into a high priority thread, and signal that thread when the interrupt occurs. This reduces nesting headaches, etc.

    If your FIFO queue is overflowing... troubleshoot your interrupt behavior.

    **The newer version of the Keil Debugger has an enhanced RTOS event window - you can see the threads and the interrupts all at once.

    www.keil.com/.../uv4_db_dbg_event_viewer.htm

    When you program errors, it should be stuck in RTX_Conf_CM.c in the function os_error() with the error code OS_ERROR_FIFO_OVF.

    You can open the event viewer and see the combination of interrupts that caused the issue. Typically this is some sort of nested interrupt issue.

    You could
    -Turn long Interrupt handlers into high priority threads
    -Use BASEMASK to mask out low importance interrupts
    -Change the priorities of the interurpts
    -Increase the FIFO size in the RTX_Conf_CM.c file

    When diagnosing interrupts,

    These windows may also be useful

    **The trace exceptions window (see the minimum, max time for a exception to enter, exit and run - useful to see if there are nesting issues):
    www.keil.com/.../ulink2_trace_exception.htm

    **Nested Vector Interrupt Controller - turn off and on exceptions:
    http://www.keil.com/support/man/docs/gsac/gsac_nvic.htm

    These windows need to have data tracing setup for the debugger:
    http://www.keil.com/support/man/docs/ulink2/ulink2_ctx_trace.htm

Children