OK - I’ve stopped calling that function in the Idle Task Hook function.
…you didn’t say if it made any difference though. I presume not.
All my other tasks call uxTaskGetStackHighWaterMark() as well each time
they come out of suspension. Should I stop calling from those tasks too
or are you just interested in the Idle Task?
The function shouldn’t make any difference, but it is the only thing
being called in the idle hook and I was looking for something that might
cause the idle to continue running.
All your symptoms point to an invalid interrupt priority. I can’t
remember - did we determine if the port you are using has the same
asserts() that the official port has for trapping that?
I just changed the Idle Task about an hour ago. It will take a few days to see if that fixes things since I have seen the CPU run as long as 48 hours before lockup.
It’s not just the Idle task that keeps running fine. All the other 3 tasks are running fine too.
Concerning interrupts - I’m using an M0+. Here is my definitiion: #define configLIBRARY_MAX_SYSCALL_INTERRUPT_PRIORITY 1
I’ve checked my vectors.c file and there are 3 devices on IRQ3. 2 I2C and 1 UART. There are 2 on IRQ2. NMI (which is not enabled) and a UART. There are 2 on IRQ1. Hard Fault and a UART. There are none on IRQ0.
I’m afraid that without having the code in front of me to debug I’m not
sure what else to suggest. I’m sure there will be a logical answer, but
its hard to determine remotely.