• State
  • Locked Locked
  • Replies 6 replies
  • Subscribers 82 subscribers
  • Views 1383 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

Setting and clearing IPC interrupt flag, memory access conflict?

Joel Mawhinney
Prodigy 20 points
Other Parts Discussed in Thread: CONTROLSUITE

I'm working with rev 0 silicon of the F28M35H52C1 and have run into what I suspect is an issue with the IPC flags' memory access control. I am setting a flag on the C28 side:

CtoMIpcRegs.CTOMIPCSET.bit.IPC2 = 1;

This is supposed to trigger an interrupt on the M3 side, where it clears the flag:

IPCCtoMFlagAcknowledge(IPC_FLAG2);

Sometimes the interrupt is delayed on the M3 side and the set and clear could coincide and I suspect this is what has caused the interrupt to stop working on the M3 side occasionally. Is this a known issue for the IPC flags and is there a workaround? Also is this addressed in rev A silicon as indicated for the shared RAM in the advisory titled "RAM Controller: Cortex -M3 Accesses to shared RAM and to MSG RAM do not work when any other master simultaneously accesses the same memory"?

Thanks!

Joel

  • 0
    TI__Expert 8950 points

    Joel,

    The application code has to check whether the flag has been acknowledged before setting it again. This can be done by polling CTOMIPCFLG.IPC2. If the C28 writes to CTOMIPCSET.IPC2 twice before the M3 can clear the flag, it will only cause one interrupt.

  • 0 in reply to Adam Haun
    Prodigy 20 points

    Thanks Adam, that makes sense. The part I'm concerned with is if the two asynchronously running processors try to set or clear the interupt flag at the same time, is there is there hardware control to avoid a bus collision? I'd like to know if this is the problem I've encountered and if so if it's been fixed in the new silicon.

    Cheers!

    Joel

  • 0 in reply to Joel Mawhinney
    TI__Expert 8950 points

    Joel,

    If the two CPUs try to set and clear at the same time, the set wins. This is the intended behavior, so no fix is planned. Software should always verify that the flag has been ACKed before trying to set it again.

  • 0 in reply to Joel Mawhinney
    TI__Expert 8950 points

    To clarify, if the flag was already set (active) when the simultaneous set/clear occurs, the set/clear will not produce another interrupt.

  • 0 in reply to Adam Haun
    Intellectual 270 points

    Hello,

    In my case doing acknowledge immediately before setting the flag (thus in C28) seems to work as coded below

    IPCCtoMFlagClear (IPC_INTERRUPT_FLAG);
    IPCCtoMFlagSet(IPC_INTERRUPT_FLAG);

    This way, at least one ack always occurs before set (even if hw collision happens). In our application C28 doesn't need to know if M3 has acked before C28 sets flag again, so the modification is acceptable.

    Anyway, I see 2 questions:

    1. C28 clock is 150MHz, M3 100MHz. If C28 sets follow immediately the clear might somehow M3 NVIC not see the interrupt?
    2. In our application C28 sets also other flags. Could some of those sets cause a collision with M3 clear of IPC_INTERRUPT_FLAG? I mean: suppose C28 wants to set IPC_xxx_FLAG when IPC_INTERRUPT_FLAG is high. It reads the whole register (with IPC_INTERRUPT_FLAG high) in order to make the or for bit IPC_xxx_FLAG . Then M3 acks IPC_INTERRUPT_FLAG in the same time C28 writes CtoMIpcRegs.CTOMIPCSET with IPC_xxx_FLAG as high. Could this be a collision for IPC_INTERRUPT_FLAG and make interrupt not generated?

    Thanks in advance.

    Regards.

    Lorenzo.

  • 0 in reply to Lorenzo Verniani
    TI__Expert 8950 points

    Lorenzo,

    1. The M3 clock is derived from the C28 clock. You should have either 150/75 MHz or 100/100 MHz. You can't get 150/100 MHz. I don't know whether a true back-to-back clear/set on the C28 side might skip the interrupt if the M3 clock is divided down. (If you try it, let me know!) But I can tell you that it you call the driver functions you shouldn't have a problem, since the function call overhead takes several cycles.

    2. You might get a read-modify-write collision if you write to the IPCFLG register directly, but you shouldn't do that. Instead use IPCSET and IPCCLR to avoid problems. (You should also do this for GPIO pin toggling.) That's what the controlSUITE driver functions do.