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.

C5505 w/DSP-BIOS - can another GP timer be used?

All:

I have the C5505 running at 65.536 MHz, with DSP-BIOS (5.41.11.38), which by default uses general purpose timer 0 and generates a clock tick every 1 millisecond.

Can GP timer 1 be used as well?

If I want to generate an interrupt, how do I do this if general purpose timer 0 is being used by DSP-BIOS?

I need to generate an interrupt every 8.33 msec. With gp timer 1, it looks like I can do that if I set the prescale to 5 and timer period of 109225. However, I am unsure of how to set up the interrupt, because it looks like it is also shared with the timer 0 Bios interrupt. Do I create a new interrupt service routine that distinguishes between a BIOS interrupt and the timer 1 interrupt?

 

  • All:

    Just spotted a flaw in my logic - the PSCDIV does not allow for divide by 5, it works in powers of 2 from divide-by-2 to divide-by-8192...

     

  • Todd Anderson,

    Have you seen the BIOS PRD module?  PRD is for "periodic" and will let you create a function that runs periodically.  You can configure how often you want it to run (period) as well as which function to run.

    You can create a new PRD from within the BIOS config file (*.tcf).  Just right click on "PRD - Periodic Function Manager" and then select "insert new PRD".  Then, you can configure the PRD instances' properites:

    Steve

  • Steve:

    Thanks for your input!

    Yes, I am aware of the PRD module, but to get the granularity needed to go 8.33 msec between periods would mean that the "usual" tick of 1 msec would suffer. I actually found another way of doing the precedure, so I do not need the timer. However, the question remains - if using a general purpose timer for the DSP-BIOS timer tick, are other GP timers available? OR is it assume that everything will be done under the Bios umbrella?

    If I choose to use one of the other GP timers, how do I handle interrupts?

     

  • Todd Anderson,

    Did you enable the GP timer interrupt?

    If so, then you should be able to map that interrupt to a HWI in BIOS.  You would configure the HWI whose number matches the GP timer interrupt to run the function (ISR) you define.

    Also, I not sure if you've already seen this but it came up in a Google search: http://www.ti.com/lit/ug/spru595c/spru595c.pdf

    Steve

  • Thanks Steve.

    However, I see some problems yet. In the DSP-BIOS GUI, I have a choice of 3 timers to use. If I pick one for DSP-BIOS (say Timer 0), BIOS creates the necessary interrupt service routine to use when servicing "timer ticks." It then looks like I have the choice to use the other 2 timers, if necessary.

    If I use Timer 1, AND I also need to have associated interrupts, then I need to be able to create an interrupt service routine that will distinguish between Timer0 interrupts and Timer1 interrupts, because of the "timer interrupt aggregation." In that interrupt service routine, I would need to "Branch" to the Timer0 interrupt service routine if it was a Timer0-associated interrupt or "Branch" to the Timer1 interrupt service routine for the Timer1-associated interrupt.

    Why is it necessary to use a general purpose timer if I can use PRDs inside of DSP-BIOS? Usually, BIOS events are clocked at a rate of around 1 msec timer ticks, and the PRDs can be set up for larger timings, around increments of milliseconds. There are times that a specific rate is needed - like 8.33 msec - to create a timer tick that would get to that would probably complicate larger timings, create more code, and add additional overhead in terms of interrupt timings.

    All of this assumes that I can use Timer1 when Timer0 is being used for DSP-BIOS. The question I still need answered:

    If Timer0 is being used by DSP-BIOS, do I have access to Timer1 and Timer2?

     

  • Hi Todd,

    I found the following in the BIOS API guide for C5000, I think this may be what you need.

    This property lets you specify the function that should run for Timer 0 - 2, as well as the argument to that function and is specific to your h/w (5505).

    (Note: looking at this, I think the value for "Tconf Name: INPUTCLK" may be incorrect and is a bug in the document.  Based on the description, I think what's shown in the Example part is what you need [bios.CLK.TIMER0FUNC]...)

    Timer 0-2 Function. Specifies the function to be executed when the
    corresponding timer interrupt occurs. (’C5505 only.)
    Tconf Name: INPUTCLK Type: Numeric
    Example: bios.CLK.TIMER0FUNC =
    prog.extern("timer0Fxn");
    Timer 0-2 Argument. Specifies the argument to be passed to the
    timer function when the corresponding timer interrupt occurs.
    (’C5505 only.)
    Tconf Name: INPUTCLK Type: Numeric
    Example: bios.CLK.TIMER0ARG = 0

    Steve

  • Steve:

    Thanks for you past answer. I noticed that the DSP/BIOS 5.42.00.07 inserts a call to _CLK_dispatch into HWI_4.

    Because it is grayed out, I cannot set up a different routine that would distinguish between the 3 interrupt sources. So, it looks like I cannot use timer interrupts for timer1 or timer2 if I am using timer0 as a BIOS timer tick.

  • I managed to get it working. I can now run timer0 as the DSP/BIOS timer and also set up timer1 to give independent interrupts. I turns out that the key was setting up the pointer to the timer1_isr routine in the CLK - clock manager. With timer0 set up for the BIOS, I was able to point at timer1 tab and set up the pointer to the isr.

    I was then able to set up the GPT functions to get timer1 going - one of the keys is to make sure that the timer1_isr function has two instructions:

        IRQ_clear(TINT_EVENT);    

       CSL_SYSCTRL_REGS->TIAFR = 0x02; // Clear Timer Interrupt Aggregation Flag Register (TIAFR)

    So far, so good. No defined need for the general purpose timers (1 & 2) yet, but there may be an independent time-out that will become necessary.