Hi everyone,
I've tried to send this message a couple of times, I apologize for any
duplicates. It's my first post, so I hope the problem description is clear
enough.
We are using the TMS320C6713BGDP225 DSP in an embedded system for measurement
and real-time analysis. The DSP code is based on DSP/BIOS and RF3. This far, we
have tested 10 units and everything works as expected. Recently we encountered a
problem with one of the previously untested boards. The code was successfully
downloaded to the SDRAM using CCS3.0 and the XDS510PP emulator, but when running
the code it hanged on a delay function, implemented using Timer 1. Code snippet
follows:
// Delay for "delay" number of 225/4 MHz cycles.
void pxDelay( Uint32 delay )
{
Uint32 ctr = 0;
ctr = TIMER_getCount( hTimer1 );
while ((TIMER_getCount( hTimer1 ) - ctr) < delay);
}
The timer was initialized using DSP/BIOS with the following parameters:
CTL = 0x00000280
PRD = 0xffffffff
CNT = 0x00000000
The timer was started with TIMER_start(hTimer) in the main() function.
Using TIMER_getCount( hTimer1 ) to monitor the counter value, it seems like it
is incremented up to 0x00c10001 and then stops, which causes the pxDelay()
function to run forever.
When disabling all functions based on Timer 1, the code runs as expected. No
other errors have been found during the testing process. Exactly the same code
has successfully been run on other units with exactly the same hardware. We are
using a 50-MHz external clock oscillator and 225 MHz system clock. The PLL seems
to do its job, since the SDRAM clock has the correct frequency.
Could this behavior result from a faulty hardware design, or do we have reason
to believe that it could be an internal error in the DSP? Anyone who has seen
similar behavior?
Thank you!
Best regards
Daniel
C6713 Timer problem
Started by ●July 8, 2005
Reply by ●July 11, 20052005-07-11
Hi Daniel,
have you checked the CNT register? Is it still at 0x00000280?
As for a HW problem I would suggest to try heating or cooling the DSP.
HTH Gustl daniel.sandstrom@dani... wrote:
> Hi everyone, I've tried to send this message a couple of times, I
> apologize for any duplicates. It's my first post, so I hope the
> problem description is clear enough.
>
> We are using the TMS320C6713BGDP225 DSP in an embedded system for
> measurement and real-time analysis. The DSP code is based on DSP/BIOS
> and RF3. This far, we have tested 10 units and everything works as
> expected. Recently we encountered a problem with one of the
> previously untested boards. The code was successfully downloaded to
> the SDRAM using CCS3.0 and the XDS510PP emulator, but when running
> the code it hanged on a delay function, implemented using Timer 1.
> Code snippet follows:
>
> // Delay for "delay" number of 225/4 MHz cycles. void pxDelay( Uint32
> delay ) { Uint32 ctr = 0; ctr = TIMER_getCount( hTimer1 ); while
> ((TIMER_getCount( hTimer1 ) - ctr) < delay); }
>
> The timer was initialized using DSP/BIOS with the following
> parameters:
>
> CTL = 0x00000280 PRD = 0xffffffff CNT = 0x00000000
>
> The timer was started with TIMER_start(hTimer) in the main()
> function.
>
> Using TIMER_getCount( hTimer1 ) to monitor the counter value, it
> seems like it is incremented up to 0x00c10001 and then stops, which
> causes the pxDelay() function to run forever.
>
> When disabling all functions based on Timer 1, the code runs as
> expected. No other errors have been found during the testing process.
> Exactly the same code has successfully been run on other units with
> exactly the same hardware. We are using a 50-MHz external clock
> oscillator and 225 MHz system clock. The PLL seems to do its job,
> since the SDRAM clock has the correct frequency.
>
> Could this behavior result from a faulty hardware design, or do we
> have reason to believe that it could be an internal error in the DSP?
> Anyone who has seen similar behavior?
>
> Thank you! Best regards Daniel > NEW! You can now post a message or access and search the archives of
> this group on DSPRelated.com:
> http://www.dsprelated.com/groups/c6x/1.php
>
> _____________________________________ Note: If you do a simple
> "reply" with your email client, only the author of this message will
> receive your answer. You need to do a "reply all" if you want your
> answer to be distributed to the entire group.
>
> _____________________________________ About this discussion group:
>
> Archives: http://www.dsprelated.com/groups/c6x/1.php
>
> To Post: Send an email to c6x@c6x@...
>
> Other DSP Related Groups: http://www.dsprelated.com/groups.php Yahoo!
> Groups Links
have you checked the CNT register? Is it still at 0x00000280?
As for a HW problem I would suggest to try heating or cooling the DSP.
HTH Gustl daniel.sandstrom@dani... wrote:
> Hi everyone, I've tried to send this message a couple of times, I
> apologize for any duplicates. It's my first post, so I hope the
> problem description is clear enough.
>
> We are using the TMS320C6713BGDP225 DSP in an embedded system for
> measurement and real-time analysis. The DSP code is based on DSP/BIOS
> and RF3. This far, we have tested 10 units and everything works as
> expected. Recently we encountered a problem with one of the
> previously untested boards. The code was successfully downloaded to
> the SDRAM using CCS3.0 and the XDS510PP emulator, but when running
> the code it hanged on a delay function, implemented using Timer 1.
> Code snippet follows:
>
> // Delay for "delay" number of 225/4 MHz cycles. void pxDelay( Uint32
> delay ) { Uint32 ctr = 0; ctr = TIMER_getCount( hTimer1 ); while
> ((TIMER_getCount( hTimer1 ) - ctr) < delay); }
>
> The timer was initialized using DSP/BIOS with the following
> parameters:
>
> CTL = 0x00000280 PRD = 0xffffffff CNT = 0x00000000
>
> The timer was started with TIMER_start(hTimer) in the main()
> function.
>
> Using TIMER_getCount( hTimer1 ) to monitor the counter value, it
> seems like it is incremented up to 0x00c10001 and then stops, which
> causes the pxDelay() function to run forever.
>
> When disabling all functions based on Timer 1, the code runs as
> expected. No other errors have been found during the testing process.
> Exactly the same code has successfully been run on other units with
> exactly the same hardware. We are using a 50-MHz external clock
> oscillator and 225 MHz system clock. The PLL seems to do its job,
> since the SDRAM clock has the correct frequency.
>
> Could this behavior result from a faulty hardware design, or do we
> have reason to believe that it could be an internal error in the DSP?
> Anyone who has seen similar behavior?
>
> Thank you! Best regards Daniel > NEW! You can now post a message or access and search the archives of
> this group on DSPRelated.com:
> http://www.dsprelated.com/groups/c6x/1.php
>
> _____________________________________ Note: If you do a simple
> "reply" with your email client, only the author of this message will
> receive your answer. You need to do a "reply all" if you want your
> answer to be distributed to the entire group.
>
> _____________________________________ About this discussion group:
>
> Archives: http://www.dsprelated.com/groups/c6x/1.php
>
> To Post: Send an email to c6x@c6x@...
>
> Other DSP Related Groups: http://www.dsprelated.com/groups.php Yahoo!
> Groups Links
