Hello,
I just had an issue which ended in an interrupt occuring two times. The situation is a bit more complex since IPC is involved but I try to describe the point where I think the problem comes from.
So I am sending a struct from one core to the other core and on the receiving core I am changing one filed of the struct. The sender changes it to 1 and the receiver changes it to 0. It now happened after some amount of time that the value suddenly already came with 0 to the receiving core which should not happen. I am referencing to the struct via a pointer and thus I change the value directly in the VRING.
So my only thought was that an interrupt seems to occur twice which uses the same field in the VRING.
I then noticed I am calling HwiP_disable and HwiP_restore (with the returned value) somwhere in the call-chain, this is due to I call a function which was previously only called from Task-context.
I then used a copy of the struct in question and the problem did not occur anymore. So my guess is that a call to HwiP_disable and HwiP_restore inside an interrupt itself will the restore its own interrupt and fires it a second time. This lead to the ipc-interrupt occuring twice using the same VRING-field.
Is this possible? I did not find any more detailed information for HwiP regarding this behaviour.
Since it's encapsulated in our own interrupt-locking-function I can just check if I am inside an ISR.
What would be a good solution then? using HwiP_disable but not with the return-value (and no HwiP_restore, but HwiP_enable?) if HwiP_inISR() != 0?
best regards
Felix
