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.

AM5749: gptimer issue with a periodic event from a DSP firmware

Part Number: AM5749
Other Parts Discussed in Thread: SYSBIOS

Hello,

I'm using an AM574x based board with Linux (5.10.x from TI tree) on the ARM core.
Now I'm testing the ARM/DSP communication (IPC) with a custom DSP firmware based on messageq_single example.

I extended the messageq_single example to use an additional gptimer with the DSP firmware (DSP1).

The gptimer is configured from a .cfg file (static configuration) to generate a 18kHz signal using a gpio.

Since we have to deal with gptimer already used by Linux OS, DSP2 and IPUs, there is no much
free/available gptimer based on the devicetree information.

gptimer1: kernel (clockevent)
gptimer2: free
gptimer3: ipu2
gptimer4: ipu2-watchdog
gptimer5: dsp1
gptimer6: dsp2
gptimer7: ipu1-watchdog
gptimer8: ipu1-watchdog
gptimer9: ipu2-watchdog
gptimer10: dsp1-watchdog
gptimer12: free but can only be clocked only from the internal oscillator
gptimer11: ipu1
gptimer13: dsp2-watchdog
gptimer14: free
gptimer15: kernel (free running counter)
gptimer16: kernel (free running counter)

Only gptimer2 and gptimer14 seems to be available (I ignore the secure gptimer12).

Lets take the gptimer14.

First, I need to add it to the dsp1 devicetree node otherwise the kernel
will try to handle the timer event (timer5 is already used for the TI-RTOS scheduler timer).

&dsp1 {
    status = "okay";
    memory-region = <&dsp1_memory_region>;
    ti,timers = <&timer5>, <&timer14>;
};

Then I create the timer from the .cfg file:

var Timer = xdc.useModule('ti.sysbios.timers.dmtimer.Timer');
var IntXbar = xdc.useModule('ti.sysbios.family.shared.vayu.IntXbar');
var TimerSupport = xdc.useModule('ti.sysbios.family.shared.vayu.TimerSupport');

TimerSupport.availMask = 0x0012; // gptimer5 & gptimer2

// gptimer2
// CSL_XBAR_INST_DSP1_IRQ_64           (33U)
// CSL_XBAR_TIMER2_IRQ                  33,
IntXbar.connectMeta(33, 33);

Timer.timerSettings[1].intNum = 15;  // gptimer2

// create a dmtimer config parameter object
// Set period to 35.714 us (1/28KHz)
var timerParams = new Timer.Params();
timerParams.period = 35.714;
timerParams.periodType = Timer.PeriodType_MICROSECS;
timerParams.runMode = Timer.RunMode_CONTINUOUS;
timerParams.startMode = Timer.StartMode_AUTO;

Timer.create(1, '&myTimerTick', timerParams);

myTimerTick is defined in the C source file:
void myTimerTick(void)
{
    UInt key;

    key = Hwi_disable();
    //GPIO_toggle(GRN_LED);
    GPIOPinWrite(SOC_GPIO1_BASE, GPIO_GRN_LED_PIN_NUM, 0);

    // WIP DSP workload
    int i=0;
    for(i=0; i<1005; i++){ // Wait for 25us
      asm(" NOP");
    }

    //GPIO_toggle(GRN_LED);
    GPIOPinWrite(SOC_GPIO1_BASE, GPIO_GRN_LED_PIN_NUM, 1);
    //Hwi_enable();
    Hwi_restore(key);

}

The signal generated by the gpio is not a periodic 28kHz signal at all.
It's just some random (unstable) level changes...

Testing with the gptimer14 give the same unexpected result.

In order to test with other gptimer I disabled the dsp2 on the devicetree to
use the gptimer6 from the dsp1:

&dsp1 {
    status = "okay";
    memory-region = <&dsp1_memory_region>;
    ti,timers = <&timer5>, <&timer6>;
};

&dsp2 {
    status = "disabled";
    memory-region = <&dsp2_memory_region>;
};

Then I updated the .cfg file with gptimer6 settings:

TimerSupport.availMask = 0x0030; // gptimer5 & gptimer6

// gptimer6
// CSL_XBAR_INST_DSP1_IRQ_68           (37U)
// CSL_XBAR_TIMER6_IRQ                  37,
IntXbar.connectMeta(37, 37);

Timer.timerSettings[5].intNum = 15;   // gptimer6

Timer.create(5, '&myTimerTick', timerParams);

With this timer the signal on the gpio is the one we expect with a small jitter.
Why have we an issue with gptimer2 and gptimer14 ?

Further testing with other timer showed that we can get only expected result with
gptimer6, gptimer7 and gptimer8 (with ipu2, ipu1 disabled).

Is something related to the eventCombiner or something else ?

Best regards,
Romain