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

  • Hello,

    This issue is due to the idlemode force-idle enabled by default.

    This was noticed after checking the CM_IPU_TIMER5_CLKCTRL register used by the TI-RTOS:

    gptimer5

    devmem2 0x4A005558 w
    Read at address  0x4A005558 (0xb6fd0558): 0x00000002

    and the CM_L4PER_TIMER2_CLKCTRL:

    gptimer2

    devmem2 0x4A009738 w
    Read at address  0x4A009738 (0xb6f7b738): 0x00020002

    I added the following line in the dsp.cfg file to use the gptimer as expected:

    // idlemode: no-idle
    timerParams.tiocpCfg.idlemode = 1;

    Do you know why force-idle is the default setting?

    Best regards,
    Romain

  • Hi Romain,

    Apologies for not responding earlier and the delay. Do you still need clarifications on this thread?

    regards

    Suman

  • Hi Suman,

    Using no-idle mode fixed the gptimer instability.
    I hope this thread could help someone else with the default mode force-idle.
    I'm closing this thread.

    Best regards,
    Romain