[Feature Request] PIC32 port, implement xPortIsInsideInterrupt

[KammutierSpule]

There is no xPortIsInsideInterrupt implemented for PIC32 ports.

There is a uxInterruptNesting but it is not clear its usage:
extern volatile UBaseType_t uxInterruptNesting;

[kstribrnAmzn]

How does #1300 work for you?

[KammutierSpule]

How does #1300 work for you?

I didn't tried yet, I may test on next week.
I left comments on your PR.

[KammutierSpule]

warning: always_inline function might not be inlinable [-Wattributes]
[build]  __attribute__((always_inline)) BaseType_t xPortIsInsideInterrupt( void )

also I got this warning, maybe it need to be created with #defines ?

[kstribrnAmzn]

Thanks for further testing this out and letting me know about the issues. I got MPLAB setup myself and polished the hasty code I wrote. It should now build without warnings. Let me know if it's working for you

[kstribrnAmzn]

@KammutierSpule have you had a chance to test out the updates I've made?

[KammutierSpule]

@KammutierSpule have you had a chance to test out the updates I've made?

I tested at last..

PIC32MZ, it does not work: ulCurrentInterrupt does not get value 0

$12
ulCurrentInterrupt
inside ISR: 0x25000401
outside ISR: 0x25000C01

IA says we should use $13

$13
outside ISR: 0x00800028
inside ISR:  0x80800400

But I couldn't find literature to understand which bit should be verified.

[KammutierSpule]

I found another possible way, by checking uxInterruptNesting

The microchip FreeRTOS "use" (ie: in MPLAB X IDE, with MCC, the code generator), it will generate interrupt_a.S code for all interrupts.

In this interrupt_a.S, all interrupts call the portSAVE_CONTEXT and portRESTORE_CONTEXT,

There is this also:
#define portASSERT_IF_IN_ISR() configASSERT( uxInterruptNesting == 0 )

This shall work, if following the Microchip implementation.

EDIT: mind that uxInterruptNesting is initialized to 1, so if any code runs before vTaskStartScheduler(), uxInterruptNesting will return 1.

[kstribrnAmzn]

Did a bit more research. I found this document outlines the various bits. Pages 50-59 and 50-60 explain register $12 (aka the status register) and page 50-69 explains register $13 (cause register).

The cause register contains the ExcCode bits which will tell you what the last exception cause was. The problem is these bits are not cleared upon exiting an interrupt - not to mention that even if they were that itself would signal an interrupt. This creates a problem where you can't tell if an interrupt happen because the bits remain set until the next interrupt. The status register has the EXL bit which is set upon entering an interrupt. This is also described here (text under the diagram).

What I don't understand is that in your testing you showed that bit 2 & 1 of the status register were not set during the interrupt. This is wrong.

[kstribrnAmzn]

I have updated my PR to check the EXL bit of the status register. Feel free to try it out.

[kstribrnAmzn]

Checking uxInterruptNesting will also work!

[KammutierSpule]

I have updated my PR to check the EXL bit of the status register. Feel free to try it out.

It didn't worked for me.

I tested again and this is what I experience:

$12
ulCurrentInterrupt
outside ISR: 0x25000001

inside ISR: 0x25000C01
or
inside ISR: 0x25000401