C6748 Timer PSC entry

Hi Roger

On c6748 the timer modules do not have a LPSC associated with them. The timer modules are very small in gate count, so clock gating them does not provide any significant power savings, therefore we did not have any LPSCs for timers.

Are you seeing any issues with making the timer work? If you were using Timer 2 on Rev 1.x silicon, please be aware of the errata item

http://focus.ti.com/lit/er/sprz303b/sprz303b.pdf

Advisory 1.1.15 Emulation Suspend Not Functional for McBSP0, McBSP1, TIMER2, and VPIF
Revision(s) Affected 1.1 and earlier
Details Device peripherals often include an emulation suspend function that gracefully halts peripheral activity. This function is activated when the target CPU is halted through
emulator debug. While halted, the control and status registers for the module can be viewed and manipulated for debug purposes. For the affected silicon revisions, the emulation suspend function for McBSP0, McBSP1, TIMER2, and VPIF is not functional – the affected peripherals will not halt when the DSP is halted.

Regards

Mukul

Hello Mukul,

The processor is a TMX. I moved the timer to Timer0 but it still did not count. It does now though - I think what was happening was that in CCS4 when I reload the program it is not resetting the registers, so the timer has reset not asserted from the last run, it seems some register fields in TCGR cannot be changed when it is not in reset & this was causing my problem. The fix was to assert reset in TCGR before setting up the other fields. To me the meaning of reset here is a bit fuzzy.

It ought to be possible to get CCS4 to reset the CPU before loading but when I ask it to do this (<tools><debug><target>) it does not appear to load a runnable program??

Regards   ---   Roger

Mukul,

Yes I saw it would not reset the whole thing. Could do with a way of doing a system reset automatically on debug......

As for the timer: In 32+32bit chained mode I have INTCTLSTAT.PRDINTEN12 set & I'm reading INTCTLSTAT.PRDINTSTAT12 in a loop, when it's set the period is expired & I write a 1 to it to reset it and then go off & do something. What is seems to do is fire a dozen times before the reset of INTCTLSTAT.PRDINTSTAT12 takes effect. I'm assuming the period compare is an edge triggered function. Anyway to proceed I have done the same thing another way.

Regards   ---   Roger

Hi Roger

roger littlewood said:

What is seems to do is fire a dozen times before the reset of INTCTLSTAT.PRDINTSTAT12 takes effect.

I didn't quite understand this, are you using chained mode continuous and are you getting multiple interrupts?

You might find this forum post helpful, if you haven't seen this already

http://e2e.ti.com/support/dsp/tms320c6000_high_performance_dsps/f/115/p/28793/100360.aspx#100360

Regards

Mukul

Hello Mukul,

To be clearer about what I am seeing operating conditions are:
Chained mode continous, Timer0, Timer 3:4 period=150, 3:4 period=100000. Auxclk=24MHz.

Software in a loop reads PRDINTSTAT12 and when it is set it will (A) reset it (write a 1), (B) output a signal to a pin which I am looking at with a scope, (C) loop again waiting for it to be set.

What I see on the scope is bursts of 5 or 6 pulses in a period of about 6us, repeating every 625ms. The repeat period is correct (i.e. 1000000 counts of 24MHz/150). If I change the Timer 3:4 period from 150 to 300 then the burst of pulses lasts about 12us. If I change Timer 3:4 period to 25 then only one pulse is output every period.

So it appears when the software writes a 1 to PRDINTSTAT12 the hardware is not resetting the bit because next time around the software again sees a 1 there. Its only after a short period of time that writing the 1 will reset the bit. Thus it seems the bit cannot be reset until the 1:2 counter has counted out of the period count, I assume it cannot do this until the next pulse from the prescaler 3:4. When the prescaler period is 150, then that time is 6.25us which is about what I see on the scope.

When I double the 3:4 period then the time burst duration doubles. When I set the period to 25 then the software loop is too slow to catch more than 1 of the events.

From the above I speculate that PRDINTSTAT12 is set whenever the count in 1:2 is at the period, and so writing a 1 to it will not reset it. I had assumed that PRDINTSTAT12 would be set on the clock edge when the counter equals the period, not held at 1 for the duration of time counter=period.

Maybe I'm doing something completely wrong here?

Regards   ---   Roger

Mukul,

I do have PLUSEN = 1. In the application I'm polling it because its a very simple case & just trying to keep it simple!  In the other thread you referenced he had not set the PLUSEN bit.

I think the user guide does need clarifying as it does not appear to say that this does not work in chained (or 64 bit?) mode. I can't see why it could not have been been made to work though. Another area that could do with clarifying is what exactly does "reset" mean - I found that some bits in TGCR could be set in reset but not when out of reset, and vice versa - also what does reset actually do.

Anyway I have got the application working by using just one 32 bit counter (no chaining) and INTCLSTAT appears to work as advertised then.

Your email had a PS asking to verify the answer - but I there was no "verify" button there.

Thanks   ---   Roger

Hello Mukul again,

Now that I replied to your answer, I see it has now given the option to verify your answer, which I have done.

Regards   ---   Roger