• State Resolved
  • Locked Locked
  • Replies 5 replies
  • Subscribers 99 subscribers
  • Views 346 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

Original question:

RTOS/AM6548: TI-RTOS error message regarding dmtimer in TI-RTOS example applications

PROCESSOR-SDK-AM65X: MCU DMTimer0 frequency mismatch when booting via SBL / PRSDK-5021

Dominic Rath
Mastermind 7420 points
Part Number: PROCESSOR-SDK-AM65X
Other Parts Discussed in Thread: SYSBIOS

Dear TI team,

a while (1+ year) ago we reported an issue where TI-RTOS examples wouldn't start due to a DMtimer0 frequency mismatch:

ti.sysbios.timers.dmtimer.Timer: line 1162: E_freqMismatch: Frequency mismatch: Expected 25000000 Hz, actual: 402154398 Hz.  You need to modify Timer.intFreq.lo to match the actual frequency.
xdc.runtime.Error.raise: terminating execution

In the related thread the answer was that CTRLMMR_MCU_TIMER0_CLKSEL was set to 1 by the ROM, choosing a 200 MHz (MCU_SYSCLK0/2) frequency for the timer input. The issues was tracked as PRSDK-5021.

With processor SDK 05.03 this was fixed by adding the following lines to board_clock.c:

/* Restoring MCU DMtimer0 FCLK to HFOSC0 (changed by ROM) */
HW_WR_REG32((CSL_MCU_CTRL_MMR0_CFG0_BASE + CSL_MCU_CTRL_MMR_CFG0_MCU_TIMER0_CLKSEL), (CSL_MCU_CTRL_MMR_CFG0_MCU_TIMER0_CLKSEL_RESETVAL));

The same code exists in processor SDK 06.00, but in 06.01 that file was moved from am65xx_idk/evm to evmKeyston3 (which makes sense, since it is not specific to IDK or EVM) and extended to use the Sciclient API to enable modules. Along that change, the line that fixed the MCU Timer0 clock input was dropped. With processor SDK 06.03, I couldn't find that line either.

For our own board we've been using the previous board_clock.c, until I realized that this causes issue with AM65x SR 2.0. I've copied the evmKeystone3/board_clock.c to our own board, and now the DMtimer0 frequency mismatch error is back. I've also verified that for example an Osal_delay() is 8x faster than it's suposed to be.

The same issue apparently also exists for J7 (probably makes sense, since AM65x and J7 share some code, from what I saw), see this thread: https://e2e.ti.com/support/tools/ccs/f/81/t/896425

Was the MCU timer0 frequency fix dropped from the SBL code by accident, or was there an intentional change, and something else changed along to make things work that I'm missing?


Regards,

Dominic

  • 0
    Mastermind 7420 points

    Before putting this workaround back in myself I checked if and how the SBL uses the MCU timers.

    It looks like the SBL uses MCU timer0 only to track overflows of the PMU cycle counter by setting up a 1 second timer:

            /* Initialize the parameters */
        TimerP_Params_init(&timerParams);
        timerParams.startMode = (uint32_t)TimerP_StartMode_USER;
        timerParams.periodType = (uint32_t)TimerP_PeriodType_MICROSECS;
        timerParams.period    = 1000000u;
        timerHandle = TimerP_create((int32_t)TimerP_ANY, (TimerP_Fxn)&osalArch_TimestampCcntAutoRefresh, &timerParams);

    The SBL seems to believe that the MCU timer 0 is running at 25 MHz, too, but the ROM left it running at 200 MHz. This casues the osalArch_TimestampCcntAutoRefresh function to be called eight times as often as intended, but of course that's not much of an issue, since all that matters is that the function is called at least once per 4 billion cycles, i.e. roughly ten seconds at 400 MHz.

  • 0 in reply to Dominic Rath
    TI__Genius 14680 points

    Dominic,

    Thank you for flagging this in your detailed post and we're reviewing. To confirm, you are not blocked by this but are submitting for improvement to the SBL, correct? Please do let me know if you are gated by anything here.

    Best regards

    Dave

  • 0 in reply to Dave Bell
    Mastermind 7420 points

    Hello Dave,

    I'm mostly interested in having this improved in the upstream sources so that we don't have to carry too many fixes around, and I want to spare others the trouble of going through issues that we have already solved. I'm not currently blocked by this, since the workaround that was included between 05.03 and 06.00 works (just moved to the new function that is using Sciclient instead of directly accessing the PSC).

    I'm also always giving TI the benefit of doubt, i.e. if there's a reason WHY this fix was dropped I'd be very curious to know. The processor SDK is complex, and just because something works for me right now doesn't mean I'm using it the way it is intended to be used.

    Regards,

    Dominic

  • 0 in reply to Dominic Rath
    TI__Genius 12760 points

    Hi Dave,

    this not an acute problem but should be fixed as the customer need to continue to maintain a problem that was already fixed upstream in their sources.
    Any comment?

    Regards,
    Bernd

  • 0 in reply to BO
    TI__Genius 14680 points

    Dominic,

    Thanks again for reporting this issue, and your patience. We've confirmed the same, and a fix is in place to be formally included to the SDK 7.1 release end-September. Unfortunately it was unable to intersect the upcoming 7.0 release, but will be corrected.

    Best regards,

    Dave