• State
  • Locked Locked
  • Replies 2 replies
  • Subscribers 32 subscribers
  • Views 301 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

MCU-PLUS-SDK-AM243X: calling HwiP_disable() and HwiP_restore() inside an interrupt

Felix Heil
Expert 1265 points

Part Number: MCU-PLUS-SDK-AM243X

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

  • 0
    TI__Guru 59710 points

    HI Felix,

    Apologies for the delay, as I am was in office due to an external event.

  • 0 in reply to Nilabh Anand
    TI__Guru 59710 points
    Felix Heil said:
    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?

    Some info on HwiP_disable - When this API is called, the CPU will no longer register any interrupt. I am not sure on HwIP_restore can restore the context of interrupt it is called in, I will need sometime to study this and also collect info from internal expert on this. I will try to get back by Thursday, In case I have not feel free to ping here.