TMS320F28377D: GPIO Interrupts on CPU2

Hello Jay,

Just to clarify since you're not including all your code here, the Interrupt_register and Interrupt_enable functions are reached at some point in your program, correct? Assuming that you are configuring the GPIO correctly for direction, then can you show me how you configure the input XBAR?

Best regards,

Omer Amir

Sorry, I took the related snippets from my code, and wasn't clear. The Interrupt_register and Interrupt_enable calls are in the main function for CPU2 before a forever loop:

void main(void)
{
    //
    // Initializes device clock and peripherals
    //
    Device_init();

    //
    // Initializes PIE and clears PIE registers. Disables CPU interrupts.
    //
    Interrupt_initModule();
    
    //
    // Initializes the PIE vector table with pointers to the shell Interrupt
    // Service Routines (ISR).
    //
    Interrupt_initVectorTable();
    
    //
    // Enable Global Interrupt (INTM) and realtime interrupt (DBGM)
    //
    EINT;
    ERTM;
    
    Interrupt_register(INT_XINT1, &OverRangeISR);
    Interrupt_enable(INT_XINT1);
    
    //
    // MAIN loop
    //
    for(;;)
    {
    
        < main code loop here>
    
    }
}

I am also using CPUTimer1 and INT_TIMER1 on CPU2, which works as expected.

The XBAR gets configured in the GPIO_setInterruptPin called from CPU1. These APIs are from C2000Ware driverlib.

This code worked just fine when it was all run on CPU1. I obviously am missing an initialization or ownership assignment when moved to CPU2, but it is not clear to me what that is.

Jay

Hello Jay,

I was talking specifically about the XBAR_setInputPin function; also, if you're configuring the GPIO for CPU2 the best thing to do is do all other GPIO configuration before calling the GPIO_setMasterCore function, as this gives control to CPU2 and this CPU I believe does not have the ability to configure GPIO, only reading/writing to it. Let me know if you try this and it still doesn't work.

Best regards,

Omer Amir

XBAR_setInputPin is called within gpio.c:GPIO_setInterruptPin function in C2000Ware.

I will switch the order of the calls and give that a try. The order works for other GPIO in the system though.

Jay

Hi Jay,

The order will not matter for CPU1 because CPU1 has control of configuring and reading/writing the GPIO, whereas I believe CPU2 only has the ability to read/write once it is given control. Let me know if it doesn't work, I will check with another expert about CPU2 permissions over peripherals.

Best regards,

Omer Amir 

Thanks, Omer. I changed the CPU1 initialization code for the GPIO to this:

    // Configure edge-triggered interrupt for pin
    GPIO_setInterruptType(GPIO_INT_XINT1, GPIO_INT_TYPE_RISING_EDGE);
    GPIO_setInterruptPin(myPin, GPIO_INT_XINT1);
    GPIO_enableInterrupt(GPIO_INT_XINT1);
    GPIO_setQualificationMode(myPin, GPIO_QUAL_ASYNC);
    GPIO_setMasterCore(myPin, GPIO_CORE_CPU2);

The behavior did not change. I will review my changeset to ensure nothing was lost during the migration.

Certainly the CPU2 permissions are vague in the documentation. Is there a good document that describes the behavior and requirements? I only found that GPIO and peripherals needed to be handled this way from a footnote in the datasheet and from C2000Ware examples.

I appreciate your help.

Jay

One possible workaround is to put all the GPIO and interrupt handling in CPU1, and pass an IPC message to CPU2 when the edge is detected. I would prefer NOT to do it this way.

Okay, I will contact another expert regarding interrupts to see if there's any additional configuration required to use XINT on CPU2.

Thank you for posting the solution Jay, I will talk to our team about creating better documentation for peripherals on multi-core systems.

Best regards,

Omer Amir