Stack leak detection

[Jeroen3]

Hi,

I'd like some feedback on a stack leak detection mechanism I've come up with.

Without nested interrupts the usage of MSTACK should be the same, if captured only in the SYSTEM_TICK_EVENT_HOOK().
I've put this together by writing SP of MSTACK to variable from the event hook. In main the value of that variable is checked against what it was the first time it was written. If it is not, chDbgPanic.
Now, on seemingly random occasions, it throws an chDbgPanic.

From what the registry tells me, this happens soon after it ran threads working with Serial or with Can.
But there is no evidence that excludes ethernet or sdio.

Is this method of detecting stack leaking effective, and reliable?
I am after all assuming ChibiOS is not using nested interrupts, right?

Thanks!

Edit: I now know there is a 40 byte mismatch.

[Giovanni]

Hi,

ChibiOS uses nested interrupts on architectures supporting them: Cortex-M.

This is why the stack depth is not always the same.

Giovanni

[Jeroen3]

Ah, I see it sets basepri to 0x20 in chSysLockFromIsr()...
And if I'm not mistaken this allows nested interrupts for the kernel and not the HAL.
Can I find a list of preemptable interrupts?

Usually I am not going this low level in arm.

[Giovanni]

Preemptable interrupts are allowed everywhere and all interrupts are preemptable depending on their priority. The only interrupts that cannot be preempted are those sitting at the highest priority level.

Giovanni

[Jeroen3]

That makes sense.
But what is preventing interrupts from running out of stack?
Should the stack size fit all enabled interrupts?

[Giovanni]

The stack must be dimensioned to accommodate the sum of "largest" ISRs at each priority level:

LargestISR(prio1) + LargestISR(prio2) + ... + LargestISR(prioN)

On the Cortex-M port, the ISR stack is positioned at beginning of RAM, an overflow would generate an exception on most MCUs because the area below is not mapped. There is no RAM to overflow on.

Giovanni

[Jeroen3]

MSTACK is indeed the first piece or memory to be allocated to the beginning of the coupled memory.
Didn't thought of it that way.

Currently I've set it to 512 bytes. That would be enough to fit two interrupt routines, assuming they to not throw an exception.
I'll set it back to 4kB, which is default. I have plenty of free memory in the coupled area (everything needs dma ). So I'll postpone this issue for now.

Would disabling nested interrupts have impact on the performance of the kernel?
I think it is safer to disable nested interrupts.