0
votes

I'm working on a Silicon Labs EFM tiny-gecko HW, running RTX using 4.22 arm tool chain. I have the following configuration for RTX: - NVIC grouping 7.1 - System Tick & Pend System service interrupt priority 224. - Both interrupts are enabled and never disabled by my code flow. - PRIMASK and BASEPRI registers are both 0.

The RTX code in my project is a few years old, and I'm not sure which version it is.

I observed the following issue: when using isr_evt_set to trigger a task from RTC interrupt, the task execution is delayed. I found that "Pend System service" interrupt is not called when RTC interrupt ends.

The isr_evt_set puts the "Pend system service" into pending state when called from the RTC interrupt. After the RTC interrupt ends, the "Pend system service" interrupt does not become active. Instead the processor resumes thread mode and executes a low priority (Power management) task.

I set the SCB register SLEEPONEXIT bit set to 0 in the RTC interrupt. The "Pend system service" interrupt is eventually executed ~4-10 RTC cycles later.

I expect "Pend system service" interrupt to run after the RTC interrupt. Can you explain why the cortex goes back into Thread mode after the RTC interrupt?

1

1 Answers

0
votes
  1. The Cortex M3 manual states that "Pend System Service" is an exception, and the processor has to return to Thread mode to service it.

  2. I found that before the RTC interrupt occurs, the task responsible for putting the system to sleep uses tsk_lock(). When isr_evt_set is called from RTC interrupt, its request to activate "Pend System Service" is buffered, and services only after the processor resumes Thread mode and uses tsk_unlock(), which immediately sets the NVIC pending flag for the "Pend System Service". Using a debugger I see PendSV_Handler() is called shortly after tsk_unlock() is called.