[Fwd: problem when using C6711 timer and TOUT as a GPIO pin]

Tien-

> I have problem with C6711 timer when using TOUT as a GPIO pin
> (with CCS-3.1, DSP/BIOS-5.2).
>
> In my configuration, Timer0 is used by CLK manager module with
> "Microseconds/Int = 100". And "Use CLK Manager to driver PRD"
> in PRD manager module is set.
> .
> .
> .
> But the real program, which is a little more complex, doesn't work.
> I am wondering about the execution sequence, or if I did some
> violation while programming the TOUT of timer. Here is the real code

DSP/BIOS does not finish its internal initialization until after main() returns. So
if you set Timer0 registers in main(), then DSP/BIOS may overwrite those settings as
it configures the timer for its own use as internal clock source. Possibly DSP/BIOS
preserves the I/O pin bit settings in the registers... not sure. But something to be
careful of.

-Jeff Start a New Thread

Dear Members,
Good Morning. I am new to this group. I want to know how TMS320C6713B( 300 MHz), is different from TMS320C6727(300MHz) in terms of Memory Interfacing and Host Port Interface. I am requesting you to through some light in this regard.
Thanks in Advance.

With regards,
svs Start a New Thread

Hello Jeff,

--- Jeff Brower wrote:
> DSP/BIOS does not finish its internal initialization
> until after main() returns. So
> if you set Timer0 registers in main(), then DSP/BIOS
> may overwrite those settings as
> it configures the timer for its own use as internal
> clock source. Possibly DSP/BIOS
> preserves the I/O pin bit settings in the
> registers... not sure. But something to be
> careful of.
>
> -Jeff

You're right about DSP/BIOS startup sequence and
main(). I had configured TOUT0 and TOUT1 in main() but
BIOS_start() which programs and starts the timer0 runs
after and it may overwrite my setting. Now I move the
TOUT configuration stuff from main to one TSK but
thing isn't change, internal timer counter still
doesn't match with GPIO signal randomly (I write more
detail about my test result in the mail to Dileepan
which is also cc to you). However, I think TOUT
configuration code is in a right place now.

I think if enabling timer to run and configuring TOUT
as GPIO can't be done as a same time is TRUE, this
must be a hardware constraint, not a DSP/BIOS hidden
policy of using the timer. Once I overwrite DSP/BIOS
timer setting in later booting stage (ofcourse, I only
overwrite CTL0 in FUNC bit and DATOUT bit), DSP/BIOS
won't intefere with this becacause later DSP/BIOS
calls to CLK module are CLK_gethtime() calls which
only read the timer registers. Am I wrong?

Thank you.
Best regards,
Tien

__________________________________________________ Start a New Thread

Tien Vuong-

> You're right about DSP/BIOS startup sequence and
> main(). I had configured TOUT0 and TOUT1 in main() but
> BIOS_start() which programs and starts the timer0 runs
> after and it may overwrite my setting. Now I move the
> TOUT configuration stuff from main to one TSK but
> thing isn't change, internal timer counter still
> doesn't match with GPIO signal randomly (I write more
> detail about my test result in the mail to Dileepan
> which is also cc to you). However, I think TOUT
> configuration code is in a right place now.
>
> I think if enabling timer to run and configuring TOUT
> as GPIO can't be done as a same time is TRUE, this
> must be a hardware constraint, not a DSP/BIOS hidden
> policy of using the timer.

I know from previous coding that the internal timer can run and TOUT can be used
independently as a GPIO. The hardware does support this, as long as software --
should it need to write to timer registers -- takes care to read current GPIO bit
settings and restore them as-is.

> Once I overwrite DSP/BIOS
> timer setting in later booting stage (ofcourse, I only
> overwrite CTL0 in FUNC bit and DATOUT bit), DSP/BIOS
> won't intefere with this becacause later DSP/BIOS
> calls to CLK module are CLK_gethtime() calls which
> only read the timer registers. Am I wrong?

I think it should be Ok.

But I'm not understanding your test and your explanations to Dileepan. What is this
about timer count matching? I thought you are using TOUT0 as an LED output, not an
input? Suggest you perform the most simple test:

1) Let simple main() function and one TSK initialize normally. TSK runs every one
sec and increments a counter.

2) In TSK, disable interrupts, on even count set Timer0 GPIO bit (output) and value
to 1. On odd count set value to 0. Re-enable interrupts.

3) Watch your LED.

What happens?

-Jeff Start a New Thread

Tien Vuong-

> You're right about DSP/BIOS startup sequence and
> main(). I had configured TOUT0 and TOUT1 in main() but
> BIOS_start() which programs and starts the timer0 runs
> after and it may overwrite my setting. Now I move the
> TOUT configuration stuff from main to one TSK but
> thing isn't change, internal timer counter still
> doesn't match with GPIO signal randomly (I write more
> detail about my test result in the mail to Dileepan
> which is also cc to you). However, I think TOUT
> configuration code is in a right place now.
>
> I think if enabling timer to run and configuring TOUT
> as GPIO can't be done as a same time is TRUE, this
> must be a hardware constraint, not a DSP/BIOS hidden
> policy of using the timer.

I know from previous coding that the internal timer can run and TOUT can be used
independently as a GPIO. The hardware does support this, as long as software --
should it need to write to timer registers -- takes care to read current GPIO bit
settings and restore them as-is.

> Once I overwrite DSP/BIOS
> timer setting in later booting stage (ofcourse, I only
> overwrite CTL0 in FUNC bit and DATOUT bit), DSP/BIOS
> won't intefere with this becacause later DSP/BIOS
> calls to CLK module are CLK_gethtime() calls which
> only read the timer registers. Am I wrong?

I think it should be Ok.

But I'm not understanding your test and your explanations to Dileepan. What is this
about timer count matching? I thought you are using TOUT0 as an LED output, not an
input? Suggest you perform the most simple test:

1) Let simple main() function and one TSK initialize normally. TSK runs every one
sec and increments a counter.

2) In TSK, disable interrupts, on even count set Timer0 GPIO bit (output) and value
to 1. On odd count set value to 0. Disable interrupts.

3) Watch your LED.

What happens?

-Jeff Start a New Thread

Hello Jeff,

--- Jeff Brower wrote:

> Tien Vuong-
>
> > You're right about DSP/BIOS startup sequence and
> > main(). I had configured TOUT0 and TOUT1 in main()
> > but BIOS_start() which programs and starts the
> > timer0 runs after and it may overwrite my setting.

> > Now I move the TOUT configuration stuff from main
> > to one TSK but thing isn't change, internal timer
> > counter still doesn't match with GPIO signal
> > randomly (I write more detail about my test result
> > in the mail to Dileepan which is also cc to you).
> > However, I think TOUT configuration code is in a
> > right place now.
> >
> > I think if enabling timer to run and configuring
> > TOUT as GPIO can't be done as a same time is TRUE,
> > this must be a hardware constraint, not a DSP/BIOS
> > hidden policy of using the timer.

> I know from previous coding that the internal timer
> can run and TOUT can be used independently as a
> GPIO. The hardware does support this, as long as
> software - should it need to write to timer
> registers -- takes care to read current GPIO bit
> settings and restore them as-is.

In my previous post (and previous coding), I wanted to
say that I supposed the internal timer can run and
TOUT can be used independently as a GPIO, and that was
the way I've coded: timer0 is used for DSP/BIOS, TOUT0
is output to LED, but my program didn't run smoothly
in reality. So my question was: what I were not aware
of or what I didn't take care of so that it went
wrong? Do I really need to restore GPIO bit setting
(CTL register, FUNC bit)? My purpose is setting FUNC 0. I think this doesn't conflict with DSP/BIOS timer
in any matter.

> > Once I overwrite DSP/BIOS timer setting in later
> > booting stage (ofcourse, I only overwrite CTL0 in
> > FUNC bit and DATOUT bit), DSP/BIOS won't intefere
> > with this becacause later DSP/BIOS
> > calls to CLK module are CLK_gethtime() calls which
> > only read the timer registers. Am I wrong?

> I think it should be Ok.
>
> But I'm not understanding your test and your
> explanations to Dileepan. What is this
> about timer count matching? I thought you are using
> TOUT0 as an LED output, not an
> input? Suggest you perform the most simple test:
>

I don't really understand what you're not
understanding about my test, but I am glad if you want
to hear again, hope you see my problem. Yes, TOUT is
LED output. In my code, CLK_gethtime() is used to get
internal timer counter and TIMER_FSET(CTL0, DATOUT,
value) is used to *output* value to LED:

/*************************************************/

start_count = CLK_gethtime();
TIMER_FSET(CTL0, DATOUT, 0);

// code to be measured execution time here
// ...

TIMER_FSET(CTL0, DATOUT, 1);
end_cound = CLT_gethtime();
if (end_count >= start_count)
time_count = end_count - start_count;
else
time_count = 0xFFFFFFFF - start_count + end_count;
/*************************************************/

With above code, LED blinking rate should match with
time_count. But sometimes they do, sometimes they
don't.

I guess what makes my explanation to Dileepan
confusing is that in my first post, I had reported a
wrong test result. And I had to correct it in the
recent email to him. Actually, my real code is
slightly diferrent with the above code, because the
real code sets both DATOUT0 and DATOUT1 of timer0 and
timer1, and in previous post, I also showed the
contexts in which they run.

> 1) Let simple main() function and one TSK initialize
> normally. TSK runs every one sec and increments a
> counter.
>
> 2) In TSK, disable interrupts, on even count set
> Timer0 GPIO bit (output) and value
> to 1. On odd count set value to 0. Re-enable
> interrupts.
>
> 3) Watch your LED.
>
> What happens?

I did the test you suggested. I used a PRD function,
not a TSK (I think there's no way to make TSK runs
every one sec, but when it's ready and the higher
priotity task releases the CPU, or the same priority
tasks run out of their time slices). The test ran as
expected: internal timer count between successive
running of the PRD is 1 sec and the LED blinks every 1
sec.

I did more tests. All runs correctly. Now I believe
that the hardware supports that, as long as software
and I believe that the wrong things in my real project
must be in my coding. Moreover, while writing this
paragraph, I receive Dileepan email, in which he gives
me clues that timer0 and TOUT0/GPIO can be used
independently.

Thanks for reminding me a about a *fresh* test.
Before, I tried to do *simple* tests, but they weren't
really simple because I didn't create a fresh project
for testing. Unfortunately, now I am still not able to
make a simple but best matching test to my real
project. My real software receives EXTINT4 from a FPGA
every 200usec (in EXTINT4 isr, my erroneous code stuff
is in). But to make the FPGA generates that IRQ,
complex things are behind, if I insert those complex
things into my fresh test project, it will be not
simple any longer. I am trying more.

Any more suggestions are appreciated.

Best regards,
Tien Start a New Thread

Tien Vuong-

> Yes, TOUT is
> LED output. In my code, CLK_gethtime() is used to get
> internal timer counter and TIMER_FSET(CTL0, DATOUT,
> value) is used to *output* value to LED:
>
> /*************************************************/
>
> start_count = CLK_gethtime();
> TIMER_FSET(CTL0, DATOUT, 0);
>
> // code to be measured execution time here
> // ...
>
> TIMER_FSET(CTL0, DATOUT, 1);
> end_cound = CLT_gethtime();
> if (end_count >= start_count)
> time_count = end_count - start_count;
> else
> time_count = 0xFFFFFFFF - start_count + end_count;
>
> /*************************************************/
>
> With above code, LED blinking rate should match with
> time_count. But sometimes they do, sometimes they
> don't.

A few comments:

1) You should disable and re-enable interrupts around each TIMER_FSET() call.

2) How long does the code take to execute? If you expect code to execute less than
100 msec, then you should be using a scope to monitor, not a blinking LED.

3) It's conceivable that when you make a CLT_gethtime() call DSP/BIOS stops your task
and let's something else run. You might find a way to "lock" the LED toggle and
CLT_gethtime() together, so you are sure there is no "space" between them.

> I did the test you suggested. I used a PRD function,
> not a TSK (I think there's no way to make TSK runs
> every one sec, but when it's ready and the higher
> priotity task releases the CPU, or the same priority
> tasks run out of their time slices). The test ran as
> expected: internal timer count between successive
> running of the PRD is 1 sec and the LED blinks every 1
> sec.

Ok. Right, use a PRD function.

> I did more tests. All runs correctly. Now I believe
> that the hardware supports that, as long as software
> and I believe that the wrong things in my real project
> must be in my coding. Moreover, while writing this
> paragraph, I receive Dileepan email, in which he gives
> me clues that timer0 and TOUT0/GPIO can be used
> independently.

Ok.

> Thanks for reminding me a about a *fresh* test.
> Before, I tried to do *simple* tests, but they weren't
> really simple because I didn't create a fresh project
> for testing. Unfortunately, now I am still not able to
> make a simple but best matching test to my real
> project. My real software receives EXTINT4 from a FPGA
> every 200usec (in EXTINT4 isr, my erroneous code stuff
> is in). But to make the FPGA generates that IRQ,
> complex things are behind, if I insert those complex
> things into my fresh test project, it will be not
> simple any longer. I am trying more.

Ok, sounds good.

-Jeff Start a New Thread