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.

F28M36P63C2: Concerto IPC-Flag

Part Number: F28M36P63C2


Dear TI team,

we use the Concerto F28M36P63C2 and got a issue with the IPC-FLAG mechanism.

Implementation description:
  - M3 setup a 'Function Call-X' to the C28 via the IPC.
  - Then the M3 waits for an Ack ('IPC_FLAG16') when the C28 receive the 'Function Call-X'.
        On Ack the M3 knows then the C28 will execute the request and the M3 can go further with operation.
        On Ack-TO the M3 knows the C28 may in trouble
  - The C28 will receive the 'Function Call-X' and set the relevant IPC-Flag 'IPC_FLAG16'.
    Then the C28 will execute the requested case.

Issue description:
In most cases no problem exist and works fine.
Typically the requested 'Function Call-X' is called based on seconds!
For performance reason the 'Function Call-X' is called as fast as possible.
This may work for a certain time and finally the M3-Ack waiting do Timeout
because the Ack for the IPC-Flag is not detected.
!However the C28 did receive the 'Function Call-X', set relevant IPC-Flag and
did execute the requested case. Just the M3 do wait for the Ack of the relevant IPC-Flag and TO.

For better explanation here the Code-Snippet

Coding M3:

    // 'uFlag' is set with 'IPC_FLAG16'
    // 'id'    is the request 'Function Call-X' on C28
    
    /* call fctCall() on C28 with a parameter */
    ipcStatus = IPCMtoCFunctionCall(&m3IpcCtrl1,
                        ((uLong*)M3_CTOM_PULLMSG)[C28_FCT1_CALL],
                        (uLong)id,
                        ENABLE_BLOCKING);
    if ( STATUS_PASS == ipcStatus )
    {
        /* wait for Ack */
        ipcDspWait = 0L;
        ipcStatus  = IPCCtoMFlagBusy( uFlag );
        while ( (M3_IPC_STATUS_PASS != ipcStatus) && (ipcDspWait<M3_IPC_WAIT_MSG_TO) )
        {
            ipcDspWait++;
            ipcStatus = IPCCtoMFlagBusy( uFlag );
        }
        if ( M3_IPC_STATUS_PASS == ipcStatus )
        {
            // go further
        }
        else
        {
            // TO
        }
    }
    /* always Ack. */
    IPCCtoMFlagAcknowledge( uFlag );
    ....


Coding C28:

    void c28IpcFctCall( Uint32 ulData )
    {
        switch( ulData )
        {
            case xyz:
                 ...
            case 'Function Call-X':
            {
                ... start requested case ...
                /* signal we recevied requested case */
                IPCCtoMFlagSet( IPC_FLAG16 );
                break;
            }
        } /* end of SWITCH() */
    } /* end of c28IpcFctCall() */


Additional Info.
In case of M3-TO, it is for sure that the C28 do receive and complete proper
the requestet 'Function Call-X'.
Also I could not see any Errata regarding the IPC-FLAG mechanism.


My question would be:
What is wrong or for what kind of reason do not see the M3 the IPC-FLAG?

Following setup is in use:

- Code Composer Studio
  Version: 6.1.2.00015
- F28M36P63C2
  M3  - 125MHz
  C28 - 125MHz


Thanks in advance & Regards
WJ

  • Hi,

    There is no known issue with IPC flag and ACK mechanism hence you do not see it in Errata document. I would suggest to double check the code to make sure the IPC sequence is proper.

    Regards,

    Vivek Singh 

  • Hi Vivek,

    thanks for feedback.

    Since the IPC-FLAG mechanism is quite simple (to synchronise M3 and C28 processes),
    so I do not know what kind of 'proper IPC sequence' (regrading the IPC-FLAG mechanism) do you mean.

    The IPC-Flag mechanism is very well illustrated (Fig 5-16) and described in the Data-Manual.

    May you pls give me some more/other reference.

    Thanks.

    Best Regards
    WJ

  • Hi,

    From IPC sequence, I mean when the flag gets set from one CPU and ack from other CPU and vice versa. As you said, these are simple flag set/clear mechanism and there is no known issue with this. You mentioned that only sometime this does not work. Any specific difference in working and non-working case?

    Regards,
    Vivek Singh
  • Hi Vivek,

    as you confirmed, it is a simple 'flag set/clear mechanism' and that is what me makes confuse.

    There is definitive NO difference in the SW-Flow between working and non-working case.


    One case that I did try to solve it was to add follwing Code in the C28 to make sure that the flag is set:

    C28 Code-Snippet:

                case 'Function Call-X':
                {
                    ... start requested case ...
                    /* signal we recevied requested case */
    #if 0
                    IPCCtoMFlagSet( IPC_FLAG16 );
    #else
                    while ( CtoMIpcRegs.CTOMIPCFLG.bit.IPC16 != 1 )
                        CtoMIpcRegs.CTOMIPCSET.bit.IPC16 = 1;
    #endif
                    break;
                }

    !However with the same result.

    Other question.
    In case the C28 set the relevant flag (here IPC16), this part of coding runs within the ISR (PieVectTable.MTOCIPC_INT1).
    It may possible that other access to the IPC-Memory (read/write Memory location only) may run at the same time.
    The C28-SW and M3-SW do periodicly update the IPC-Memory location outside of a ISR.
    The M3-SW to detect the relvant IPC-Flag runs also regular outside of a ISR.

    Is there any restrictions during a IPC-Memory R/W and other activities like R/W IPC-Flag at the same time?


    Thanks & Regards


    WJ

  • Hi,

    Is there any restrictions during a IPC-Memory R/W and other activities like R/W IPC-Flag at the same time?

    No, there is no known restriction. Both are independent. I still think that handshake between C28 and M3 code is getting in some kind of race condition hence causing this issue.  

    Vivek Singh 

  • Hi Vivek,

    FYI, I choosed a different way to solve this issue.

    Thanks for support.

    Best regards
    WJ