3

I'm trying to use FreeRTOS's xSemaphoreGiveFromISR function and the accompanying portEND_SWITCHING_ISR macro to give a semaphore from within an interrupt that handles the end of an I2C transaction.

Every time I do, I end up in my program's application stack overflow hook function. The only change from a working version has been adding this line to the ISR, and I've doubled the size of the stack from 8192 to 16384 which didn't help.

Does anyone have thoughts about what gotcha is getting me?

My configCHECK_FOR_STACK_OVERFLOW value is 1.

Mateusz Piotrowski
  • 8,029
  • 10
  • 53
  • 79
Doug McClean
  • 14,265
  • 6
  • 48
  • 70
  • 1
    What processor are you using? Does it have a separate stack that is used for ISRs, or just one common stack? If there is an ISR stack, is that one big enough? – TJD Jan 12 '12 at 01:41
  • @TJD It's a Cortex M3 inside a Cypress PSoC5 device. Good question if there is an separate ISR stack, I don't know. I also don't know how to configure it if there is. – Doug McClean Jan 12 '12 at 01:58
  • If I understand the documentation, there is one stack for running the main function up until the scheduler starts which is also for interrupt handling. Then each task has its own stack. I had doubled both the size of the main stack and the constant I had been using for the size of all of my task stacks, to no effect. – Doug McClean Jan 12 '12 at 02:18
  • I'm starting to wonder if it has something to do with interrupt priorities. If I understand what should happen, the software interrupt shouldn't fire right away as soon as `portEND_SWITCHING_ISR` sets it, instead it shouldn't happen until after the unwind from the original interrupt? – Doug McClean Jan 12 '12 at 04:58
  • The Cortex has two stacks, MSP (main stack pointer) and PSP (process stack pointer). MSP is used in ISR context, PSP when running tasks – TJD Jan 12 '12 at 17:19
  • Post your code please. It seems like to me that if your app stack is overflowing, the bug is not in the ISR but in the app code that consumes the semaphore. 8K of stack for an embedded tasks is huge, so you are probably overflowing it with a recursive call that does not terminate. – Mark Lakata Jul 17 '13 at 05:52
  • Make sure your pended interrupt service routine has the lowest priority. Cortex-M3 allows nested interrupts, and you should not context switch in the nesting. Look at section http://www.freertos.org/a00110.html#kernel_priority – albin Aug 05 '13 at 17:55

1 Answers1

1

You may want to check that the Interrupt is running at the same priority level than the RTOS configKERNEL_INTERRUPT_PRIORITY.

It's not unfortunately clearly stated.

I've run into the same problem as the RTOS default configuration set the interrupt priority lower than the default of the chip, at least for Microchip devices.

You also need to have enough memory for each task to handle the priority and if you have any taskYield it has to be the last instruction of the interrupt.

Damien
  • 1,492
  • 10
  • 32