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.

Using Timer1 with DSP/BIOS on the C6748

Other Parts Discussed in Thread: SYSBIOS

Hi,

I'm trying to setup Timer1 to use as a milli-timer on our system (the Logic PD Zoom Development board with the C6748 SOM). My configuration is as follow:

- C6748 DSP

- CCS 5.1.1 with DSP/BIOS v5.41.11.38,  Code generation tools v7.3.2

- EDMA3 LLD v1.11.03.01

- PSP drivers v1.30.01 for the C6748

I'm using the PSP drivers for the I2C0 peripheral drivers and the CSLR macros to access the Timer1 registers. My goal is to toggle an LED through the port expander (I2C0) and then measure the time between toggles with Timer1 in 32-bit unchained mode. However, the problem is that I can't seem to get all of these to work together. From my understanding DSP/BIOS uses Timer0 by default and should not affect Timer1 in any other way unless specifically configured that way. I suspect that it might have something to do with the pinmux, but I'm not sure. Here is my configuration of Timer1:

    _timer1_prd = timer_period;

    // Set TM64P_OUT12 and TM64P_IN12 as GPIO pins
    CSL_FINST(tmr1_regs->GPINTGPEN, TMR_GPINTGPEN_GPENO12, GPIO);
    CSL_FINST(tmr1_regs->GPINTGPEN, TMR_GPINTGPEN_GPENI12, GPIO);

    // Configure TM64P_OUT12 and TM64P_IN12 as ouputs in GPIO mode
    CSL_FINST(tmr1_regs->GPDATGPDIR, TMR_GPDATGPDIR_GPDIRO12, OUTPUT);
    CSL_FINST(tmr1_regs->GPDATGPDIR, TMR_GPDATGPDIR_GPDIRI12, OUTPUT);


    // Stop and reset Timer1
    tmr1_regs->TGCR = 0x00000000;
    tmr1_regs->TCR = 0x00000000;

    // Disable and clear all interrupts
    tmr1_regs->INTCTLSTAT = 0x00000000;

    // Set emulation to free run mode
    CSL_FINST(tmr1_regs->EMUMGT, TMR_EMUMGT_SOFT, INCREMENT);
    CSL_FINST(tmr1_regs->EMUMGT, TMR_EMUMGT_FREE, FREE);

    // Configure Timer1 for 32-bit unchained mode
    CSL_FINST(tmr1_regs->TGCR, TMR_TGCR_TIMMODE, 32BIT_UNCHAIN);
    CSL_FINS(tmr1_regs->TGCR, TMR_TGCR_PSC34, 0x1);

    // Set the period for Timer1 3:4
    tmr1_regs->TIM34 = 0x00000000;
    tmr1_regs->PRD34 = _timer1_prd;

    // Enable Timer1 3:4 for continuous reload mode
    CSL_FINST(tmr1_regs->TCR, TMR_TCR_ENAMODE34, EN_CONT);

    // Take Timer1 3:4 out of reset
    CSL_FINST(tmr1_regs->TGCR, TMR_TGCR_TIM34RS, NO_RESET);

Can someone please provide me with some insight into the problem??

Regards

  Reinier

EDIT: I do not want to use interrupts in any way on Timer1, I just want to read TIM34 and deduce the elapsed milli-seconds from the reading, based on the previous reading.

  • I'm not at all familiar with the CSL APIs but since timer0 and timer1 are within the same physical Timer64, if the CSL APIs for timer 1 don't preserve  the registers shared between the two timers (ie if they don't use &= and !=) then timer0's settings could get written over.

    Alan

  • Hi Alan,

    Thanks for your reply, I have not quite considered that, although its so obvious!

    Are you aware of other pitfalls when configuring these timers? They seem to be much more complicated and subtle than I expected.

    Regards

     Reinier

  • Reinier,

    Can you please refer the CSLr example available in the PSP 1.30.01 in the path "pspdrivers_01_30_01\packages\ti\pspiom\cslr\evm6748\examples\timer\src"?

    Hope this would help you.

    Regards,

    Sandeep K

  • Alan DeMars said:

    I'm not at all familiar with the CSL APIs but since timer0 and timer1 are within the same physical Timer64, if the CSL APIs for timer 1 don't preserve  the registers shared between the two timers (ie if they don't use &= and !=) then timer0's settings could get written over.

    Alan

    Alan,

    I guess I answered that one a little too quickly! From the Technical Reference Manual (spruh79a.pdf) each timer module has its own set of registers, so there a no registers shared between timers, except perhaps the way in which the PINMUX registers are configured.

    I also tried the example that came with the PSP drivers, on its own it works just fine, but when I integrate it with my DSP/BIOS application the program hangs whenever a SEM_pend() call is made. I suspect the Timer1 configuration affects DSP/BIOS in some way and the only way I can think of is through the configuration of the pins. From the Techninacal reference manual:

    Normal timer counting modes cannot be used when the GPIO mode is enabled -- TIM12RS in the timer
    global control register (TGCR) cannot be brought out of reset when either GPENO12 or GPENI12 in
    GPINTGPEN is asserted.

    I did clear those bits, but it did not seem to make any difference. Any ideas?

  • I dug into this a little more and discovered that the SYS/BIOS timer64 Timer module needs to know whether it is in charge of setting up the GPIO registers and bringing the device out of reset. By default, it performs these operations. So I suspect that CSL and SYS/BIOS are not setting up the GPIO registers consistently.

    Tor configure SYS/BIOS to leave this work up to CSL, add the following to your config script:

    var Timer = xdc.useModule('ti.sysbios.timers.timer64.Timer');

    Timer.timerSettings[0].master = false;

    This will prevent the SYS/BIOS timer code from initializing the GPIO registers.

    However, it also prevents SYS/BIOS from setting the unchained timer mode in the TGCR and bringing the timer half it is managing out of reset as it expects someone else to have performed this operation.

    I'm taking a guess here, but I think if you also add this to your C code:

        // Take Timer1 1:2 out of reset
        CSL_FINST(tmr1_regs->TGCR, TMR_TGCR_TIM12RS, NO_RESET);

    It may resolve this last register initialization conflict.

    Alan

  • Alan,

    Thanks for your reply, I am however, using DSP/BIOS (v5.41.11.38) and from my understanding there is quite a big difference between DSP/BIOS and SYS/BIOS, so I'm not exactly sure how applicable your advice is to my DSP/BIOS.

    I also further investigated what DSP/BIOS does with the timers and I found out that the TCR and TCGR registers were modified by DSP/BIOS before my configuration code executed. As it turned out the simple (and quite embarassing) reason for this was that DSP/BIOS, for some strange reason, used Timer1 by default and not Timer0. By explicitly selecting Timer0 as the DSP/BIOS timer solved all of my problems:

    bios.CLK.TIMERSELECT = "Timer 0";

  • I'm very glad the solution was so simple!

    Alan