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.

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

Part Number: AM6548
Other Parts Discussed in Thread: AM6546, SYSBIOS

Tool/software: TI-RTOS

Hi,

we tried building a TI-RTOS example application following the instructions from the processor sdk documentation:

http://software-dl.ti.com/processor-sdk-rtos/esd/docs/latest/rtos/index_examples_demos.html#arm-cortex-r5

We had problems before with SDK version 05.01 where the SBL was unable to load the application from a SD card (see https://e2e.ti.com/support/processors/f/791/p/750685/2778897?tisearch=e2e-quicksearch&keymatch=am6546#2778897?).

The SBL problems are gone with version 05.02, but we get an error about dmtimer frequency mismatch:

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

There are older posts about a similar problem, but that issue appears to be fxied in the SYS/BIOS version that comes with SDK 05.02:

Defects Fixed in SYS/BIOS 6.73.00 (Fixes since SYS/BIOS 6.70.00):

SYSBIOS-689 dmtimer Timer_checkFreq() failure due to caching


We're not sure if the dmtimer would have worked with SDK 05.01, but at least we didn't get that error message back then when we loaded the application via the debugger. With 05.02 we get that error message both when using the debugger and when loading the application via SBL from a SD card.

Is there a known issue regarding the dmtimer stuff on AM654x R5F with SDK 05.02? Are there any instructions on how these things should be set up, in case we're missing some necessary manual setup steps?



  • Dominic,

    Is it possible for you to provide the test project or the binary that you are using where you observe this issue.

    Also, I would recommend that you look at one of our driver test projects for R5 and apply the following fix.

    var dmtimer = xdc.useModule('ti.sysbios.timers.dmtimer.Timer');
    for (var i = 0; i < 4; i++) {
        dmtimer.intFreqs[i].lo = 25000000;
        dmtimer.intFreqs[i].hi = 0;
    }

    Example:

    pdk_am65xx_1_0_3\packages\ti\drv\uart\test\am65xx

    I believe the issue is caused due to BIOS enforcing a timer check to ensure that there is no mismatch.

    Regards,

    Rahul 

    PS: As explained here, you can also disable the timer frequency check using the following setting:

    https://e2e.ti.com/support/legacy_forums/embedded/tirtos/f/355/t/144526?dmtimer-frequency-mismatch-redux

  • Hi,

    I tried modifying the example project with the fix that you suggested, but that didn't affect the results.

    Right now we're using the "Hello Example" from the TI resource explorer classic following the guide in the processor SDK documentation:

    http://software-dl.ti.com/processor-sdk-rtos/esd/docs/latest/rtos/index_examples_demos.html#arm-cortex-r5

    (we followed the guide step by step)

    I'll attach an archive with two projects, one that is just the "Hello Example", the other is extended with your fix.

    After some more investigation it appears that the problem only occurs when the AM65x has been booted from the SD card with SBL first.

    If I boot the processor with the prebuilt SD card image from processor_sdk_rtos_am65xx_5_02_00_10\prebuilt-sdcards\am65xx_idk\sd_card_img and then load the hello example application via the debugger I get the error message about the frequency mismatch.

    If I remove the SD card with the prebuilt SD card image, power cycle the board, and use the debugger to load the example application, I don't get the error message.

    Our ultimate goal is to have a TI-RTOS application that gets loaded from OSPI via the SBL, so we need to figure out what initialization is necessary to get a working TI-RTOS application.

    I figured out that the code is verifying the frequency of MCU_TIMER0 (address 0x40400000). It seems that this timer is not (properly) initialized when the application is run after the SBL. I'm not sure if/where/how the MCU_TIMER0 ought to be initialized.

  • Dominic,

    Can you confirm that the R5F application is working when loaded over emulator and only fails when loaded using SBL QSPI boot ? Does the issue also occur with bare-metal application like R5F SBL examples or does this occur only with TI RTOS application.

    Did you also try to disable the timer frequency check as explained by Karl in the E2E here:
    e2e.ti.com/.../144526

    you can add following to the TI RTOS configuration:
    Timer.checkFrequency = false

    Regards,
    Rahul

    PS: I am currently working with the secondary bootloader developer to see if there is a known issue with this usecase and will keep you posted.

  • Hello Rahul,

    it works only if the AM65x wasn't initialized by the SBL before - if the SBL was run before, it fails, even if loaded via the emulator. In case the SBL was running before, the emulator detects this, and does "nothing". If the SBL wasn't run before the emulator initializes lots of stuff via the GEL files. I believe this means that the GEL files perform some necessary initialization that neither the SBL nor the TI-RTOS example application does.
    My problem is that I don't know which part of the system is supposed to initialize the timers.
    Disabling the timer frequency check works, but that means that the TI-RTOS timers wont work, and eventually we're going to need those timers.

    Regards,

    Dominic
  • Dominic,

    I will try to reproduce this at my end and try to see if I can identify the missing configuration between GEL and SBL. One other question : Do you load the SYSFW when loading the RTOS application or are you only running the basic GEL setup when the code is working for you.

    Regards,
    Rahul
  • Hello Rahul,

    I'm following the "Basic CCS Setup" guidelines described here: software-dl.ti.com/.../index_how_to_guides.html

    I haven't tried the Advanced setup that is also loading SYSFW to the DMSC.

    Regards,

    Dominic
  • Dominic,

    The Advanced CCS Setup is more like the bootloader setup as in it relies on the DMSC_M3 firmware(SYSFW) to setup the clocks and PSC for the device rather than just the GEL files. The setup does run the GEL and then installs the SYSFW to allow for application development.

    CCS Basic setup is only meant for basic board bring up and confirm DDR and clock setup. We recommend that all application developers use Advanced setup with SYSFW especially when using interrupt, udma and power management as the DMSC is meant to be the system master that is responsible for resource management and power management .

    Regards,
    Rahul
  • Hello Rahul,
    the point is that the application is working if the system is initialized only by the CCS basic setup. It fails if the system is initialized by the SBL, which loads the SYSFW.

    Power Cycle -> CCS Basic Setup -> Load Hello Application -> Works
    Power Cycle -> SBL Boots -> CCS Basic Setup -> Load Hello Application -> Timer Mismatch
    Power Cycle -> SBL Boots -> Load Hello Application from SD -> CCS Basic Setup -> Load Hello Application Symbols -> Application is stuck in abort due to timer mismatch

    In case the SBL booted before the GEL scripts used by CCS Basic Setup actually do nothing:

    DMSC_Cortex_M3_0: GEL Output: Reconnecting to the M3.
    DMSC_Cortex_M3_0: GEL Output: Nothing to do. AM65xEVM is already configured.
    MCU_PULSAR_Cortex_R5_0: GEL Output:

    ====

    Nothing to do. DDR4 is already initialized.

    ====

    So the point is: Even the CCS Basic Setup does something to the system that makes dmtimer work, whereas SBL doesn't perform (or breaks) that setup.

    Regards,

    Dominic
  • Dominic,

    I believe that I have finally been able to root cause the issue with the timer mismatch.

    The root cause for this issue is the CTRLMMR_MCU_TIMER0_CLKSEL state after the ROM has executed sets the DMtimer functional clock to 0x1 which uses the MCU_SYSCLK0/2 (400/2) as the functional clock. RTOS application expects that the DMtimer FCLK is HSOSCCLK0 (25 Mhz) which is the default based on the value of CTRLMMR_MCU_TIMER0_CLKSEL register setting.

    To fix this issue the GEL implements a function called timer0_cleanup when you connect to the R5F in CCS. In case of the SBL, it loads the DSMC firmware and configures the PLL but doesn`t seem to be modifying the CTRLMMR_MCU_TIMER0_CLKSEL value back to zero.

    If you add code to the SBL to unlock the CTRLMMR and then change the CLKSEL register for timer0 to set it to 0 then you should get the correct timer behavior booting from the SBL. you can refer to the timer0_cleanup function in GEL to implement this fix in the SBL.

    I have filed a bug PRSDK-5021 for this to be addressed in SBL.

    Regards,
    Rahul