AIC23 | C5509 | CCS | CSL | EMIF | EVM | GEL | GPIO | HPI | Interfacing | JTAG | McBSP | OMAP | Omap15 | OMAP59 | RTDX | SDRAM | TMS320VC5509 | USB | XDS5

We have a custom design c5509a board. When we set the clkmd to 2512,
everything is ok but when we set the value to 0x2892 ( and we have to run the
code at this speed) the code sometimes run but sometimes hangs on. I saw some
suggestions on internet to disable the clkout pin on
http://e2e.ti.com/forums/p/12107/47323.aspx and also in
http://www.dsprelated.com/groups/c55x/show/979.php.

Why do we have to disable it. And in general do you have any ideas about this
problem. First I thought that our core voltage is not enough to run on this
speed and increased it a little to 1.72Volt but the problem is still there. 

Is there a problem on c5509a about the pll or something.

Target : c5509a
Crystal : 12 Mhz
Emulator : xds510 usb plus
CC Studio 3.1
DSP/BIOS was USED in the project
CLKMD value : 0x2892
Used peripherals in design : EMIF for sdram, codec processing, SPI, I2C nearly
all of the peripherals

waiting for your urgent reply

______________________________
New Code Sharing Section now Live on DSPRelated.com. Learn about the Reward Program for Contributors here.



(You need to be a member of c55x -- send a blank email to c55x-subscribe@yahoogroups.com )

Ertan-

> We have a custom design c5509a board. When we set the clkmd to 2512,
everything is ok but when we set the value to
> 0x2892 ( and we have to run the code at this speed)

What PLL multiplier?  Do you have external memory attached?  If so is it SRAM or
SDRAM?  What if you decrease the PLL
by one?  Did you try a clock oscillator input instead of crystal?

> the code sometimes run but sometimes hangs on. I saw some
> suggestions on internet to disable the clkout pin on
http://e2e.ti.com/forums/p/12107/47323.aspx

The E2E post discusses an EMI issue -- that means when the TI customer runs the
C5509A at 192 MHz, their product
generates some RF noise that either interferes with some other circuitry or
causes them to fail an EMC test.  So they
want to dither the clock to avoid a spike at 192 MHz.  That is not the same
issue -- your problem is your code hangs.

> and also in
> http://www.dsprelated.com/groups/c55x/show/979.php.
>
> Why do we have to disable it. And in general do you
> have any ideas about this problem.

In the post above (from 2006), I asked Mitko some questions, I would ask you the
same questions.

-Jeff

> First I thought that our core
> voltage is not enough to run on this speed and increased
> it a little to 1.72Volt but the problem is still there.
>
> Is there a problem on c5509a about the pll or something.
>
> Target : c5509a
> Crystal : 12 Mhz
> Emulator : xds510 usb plus
> CC Studio 3.1
> DSP/BIOS was USED in the project
> CLKMD value : 0x2892
> Used peripherals in design : EMIF for sdram, codec processing, SPI, I2C
nearly all of the peripherals
>
> waiting for your urgent reply

______________________________
New Code Sharing Section now Live on DSPRelated.com. Learn about the Reward Program for Contributors here.



(You need to be a member of c55x -- send a blank email to c55x-subscribe@yahoogroups.com )

Since you have a custom design C5509A board, the most likely source  
of your problems is the board layout.  Is this a 6-layer board?  4- 
layer?  Every pin and every wire can be a source of EMI unless  
carefully controlled.

Regarding CLKOUT, if you're not using it, then why do you care  
whether or not it is disabled?  When it is enabled, it adds EMI to  
the system, which makes your problem worse.

Recommended Operating Conditions for this chip running at 200 MHz  
specify a maximum of 1.65V, so why are you using 1.72V?  That could  
cause problems in itself.

Finally, if your firmware code sometimes hangs, how can you be sure  
that it is not a software error?  I doubt that the PLL has any problems.

Brian Willoughby
Sound Consulting
On Nov 12, 2009, at 14:36, e...@hotmail.com wrote:
We have a custom design c5509a board. When we set the clkmd to 2512,  
everything is ok but when we set the value to 0x2892 ( and we have to  
run the code at this speed) the code sometimes run but sometimes  
hangs on. I saw some suggestions on internet to disable the clkout  
pin on http://e2e.ti.com/forums/p/12107/47323.aspx and also in http:// 
www.dsprelated.com/groups/c55x/show/979.php.

Why do we have to disable it. And in general do you have any ideas  
about this problem. First I thought that our core voltage is not  
enough to run on this speed and increased it a little to 1.72Volt but  
the problem is still there.

Is there a problem on c5509a about the pll or something.

Target : c5509a
Crystal : 12 Mhz
Emulator : xds510 usb plus
CC Studio 3.1
DSP/BIOS was USED in the project
CLKMD value : 0x2892
Used peripherals in design : EMIF for sdram, codec processing, SPI,  
I2C nearly all of the peripherals

waiting for your urgent reply

______________________________
New Code Sharing Section now Live on DSPRelated.com. Learn about the Reward Program for Contributors here.



(You need to be a member of c55x -- send a blank email to c55x-subscribe@yahoogroups.com )

I want to add some information

1. What PLL multiplier?  

PLL Mult : 10 
Crystal : 12Mhz 
so working speed : 120 MHz
Situation :Evertthing is OK
Situation 2 Above 10 the code hangs

___________________________________________________________________________
2. Do you have external memory attached?  If so is it SRAM orSDRAM?  What if you
decrease the PLL

Nearly everything :) : SRAM, FRAM, SDRAM, FLASH, NANDFLAS, four 3-state
multiplexer, ten or more logic gates, C5509A 

___________________________________________________________________________
3.What if you decrease the PLL by one?  

Actually in our lab works, we built ONE board (ıt is our first test drive
card). When we were sure that this card was working properly we started to
design our software based on 204MHz (Our delays, timers, FFT processes etc) and
sent the card  to the serial production We encountered some reset situations,
some debug problems, software hangs problems and started to investigate the core
problem and looked nearly all of the IC pins on board, the core voltage and IO
voltages on card, 12Mhz clock frequency. Everything is OK. Then I changed the
PLL frequency just to try and everything was OK. So I started to decrease the
PLL mult from 17 one by one. And I see that pll mult : 10 is the minimum working
frequency of this card. Of course I could set this value below 10. But I couldnt
set it above 10.

___________________________________________________________________________
4. Did you try a clock oscillator input instead of crystal?

No I don't

___________________________________________________________________________
5.  Is this a 6-layer board?  4- layer? 

Te board has 8 layers

___________________________________________________________________________
6. Regarding CLKOUT, if you're not using it, then why do you care  
whether or not it is disabled?

I really don't care the CLKOUT. I could find only this information on the
internet that MITKO says in a topic. I think he encountered the same problem.
Because of that I want to ask if someone know better than me about the CLKOUT 

___________________________________________________________________________
7. Recommended Operating Conditions for this chip running at 200 MHz  
specify a maximum of 1.65V, so why are you using 1.72V?  That could  
cause problems in itself.

The main problem is not 200 Mhz  + 4 MHz. The main problem is I don't want to
run the C5509A on 120 MHz. It is a low speed for the application. It can 180,
192, or 200 MHz.  But our card can not exceed 120 MHz. I want to understand why
this is happening on our board. Every IC on board, EMIF interface, SPI
interfaces, CODEC interfaces, audio processes are runnunig on 120MHz. But when I
change it to the nearest high PLL Mul: 11 It means 132 Mhz, the code hangs. ( I
tried all of the PLL Mult above 10)

Yes the core voltage is 1.6V. But in my opinion this core voltage is another
bench topic. Let me clear this.

----When the cpu is in idle state I set the core voltage to 1.6V

----When I encountered this ridicilious problem on PLL, I thought there is a
core voltage problem. So I measured the core voltage, while the code was very
active  process. I see that this voltage was less than the idle core voltage. So
I adjusted the core voltage to 1.6V when the code is running. But with this
adjusment, idle core voltage is 1.714V. I know it shouldn't exceed 1.65V but put
yourself  to me if you have such a ridicilious situtaion. 

___________________________________________________________________________
8. Finally, if your firmware code sometimes hangs, how can you be sure  
that it is not a software error?  I doubt that the PLL has any problems.

Please see my comment on 3.

______________________________
StarterWare provides C-based no-OS platform support for the C6000 DSP devices.
Click here for details.



(You need to be a member of c55x -- send a blank email to c55x-subscribe@yahoogroups.com )

Ertan-

> I want to add some information
>
> 1. What PLL multiplier?
>
> PLL Mult : 10
> Crystal : 12Mhz
> so working speed : 120 MHz
> Situation :Evertthing is OK
> Situation 2 Above 10 the code hangs

My guess is that you're trying to do too much and need to sub-divide the
problem.  Another guess is that actually
you're running at a different rate than you think.  Be sure to measure CLKOUT
and verify according to the data sheet.

To debug, suggest:

1) Make a small build, no DSP/BIOS, just main() function that doesn't do much. 
Maybe toggle a GPIO line.

2) Do not initialize SRAM, SDRAM, or any other peripheral attached to EMIF.  Use
only internal SRAM for the small test
build.

3) Use 1.6V Vcc.  Don't go higher.  You should have several 0.1 uf and 0.01 uF
decoupling caps on 1.6V.  Also you
should have some large values (40 uF, 100 uF) on the Vcc rail, both near the
regulator and near the C5509A.  If not
add more (chip caps).  Keep lead lengths super short (solder chip caps
together).  When the small code is running,
there should *not* be any drop in Vcc or increase in ripple.  If there is, you
may have a V-regulator issue (or not
enough decoupling).

4) Also measure 3.3V when the test code is running.  Same comments as 3) apply.

5) Verify code runs at PLL multiplier 11-17 etc.

Get this far, and report your results.

If the above doesn't work but CLKOUT is correct at highest known-good PLL
multiplier, and Vcc's measure stable and
correct value, then suggest pull off the 12 MHz crystal and dead-bug on a 12 MHz
clock oscillator (or 12.288 or some
approx value).  Use the existing crystal pads (XTAL1, XTAL2) and keep lead
lengths *very short* .

-Jeff

>
___________________________________________________________________________
> 2. Do you have external memory attached?  If so is it SRAM orSDRAM?  What
if you decrease the PLL
>
> Nearly everything :) : SRAM, FRAM, SDRAM, FLASH, NANDFLAS, four 3-state
multiplexer, ten or more logic gates, C5509A
>
>
___________________________________________________________________________
> 3.What if you decrease the PLL by one?
>
> Actually in our lab works, we built ONE board (ıt is our first test
drive card). When we were sure that this card was
> working properly we started to design our software based on 204MHz (Our
delays, timers, FFT processes etc) and sent
> the card  to the serial production We encountered some reset situations,
some debug problems, software hangs problems
> and started to investigate the core problem and looked nearly all of the IC
pins on board, the core voltage and IO
> voltages on card, 12Mhz clock frequency. Everything is OK. Then I changed
the PLL frequency just to try and everything
> was OK. So I started to decrease the PLL mult from 17 one by one. And I see
that pll mult : 10 is the minimum working
> frequency of this card. Of course I could set this value below 10. But I
couldnt set it above 10.
>
>
___________________________________________________________________________
> 4. Did you try a clock oscillator input instead of crystal?
>
> No I don't
>
>
___________________________________________________________________________
> 5.  Is this a 6-layer board?  4- layer?
>
> Te board has 8 layers
>
>
___________________________________________________________________________
> 6. Regarding CLKOUT, if you're not using it, then why do you care
> whether or not it is disabled?
>
> I really don't care the CLKOUT. I could find only this information on the
internet that MITKO says in a topic. I think
> he encountered the same problem. Because of that I want to ask if someone
know better than me about the CLKOUT
>
>
___________________________________________________________________________
> 7. Recommended Operating Conditions for this chip running at 200 MHz
> specify a maximum of 1.65V, so why are you using 1.72V?  That could
> cause problems in itself.
>
> The main problem is not 200 Mhz  + 4 MHz. The main problem is I don't want
to run the C5509A on 120 MHz. It is a low
> speed for the application. It can 180, 192, or 200 MHz.  But our card can
not exceed 120 MHz. I want to understand why
> this is happening on our board. Every IC on board, EMIF interface, SPI
interfaces, CODEC interfaces, audio processes
> are runnunig on 120MHz. But when I change it to the nearest high PLL Mul:
11 It means 132 Mhz, the code hangs. ( I
> tried all of the PLL Mult above 10)
>
> Yes the core voltage is 1.6V. But in my opinion this core voltage is
another bench topic. Let me clear this.
>
> ----When the cpu is in idle state I set the core voltage to 1.6V
>
> ----When I encountered this ridicilious problem on PLL, I thought there is
a core voltage problem. So I measured the
> core voltage, while the code was very active  process. I see that this
voltage was less than the idle core voltage. So
> I adjusted the core voltage to 1.6V when the code is running. But with this
adjusment, idle core voltage is 1.714V. I
> know it shouldn't exceed 1.65V but put yourself  to me if you have such a
ridicilious situtaion.
>
>
___________________________________________________________________________
> 8. Finally, if your firmware code sometimes hangs, how can you be sure
> that it is not a software error?  I doubt that the PLL has any problems.
>
> Please see my comment on 3.

______________________________
New Code Sharing Section now Live on DSPRelated.com. Learn about the Reward Program for Contributors here.



(You need to be a member of c55x -- send a blank email to c55x-subscribe@yahoogroups.com )

> Ertan- 
> 
>> I want to add some information 
>>
>> 1. What PLL multiplier? 
>>
>> PLL Mult : 10
>> Crystal : 12Mhz
>> so working speed : 120 MHz
>> Situation :Evertthing is OK
>> Situation 2 Above 10 the code hangs
> 
> My guess is that you're trying to do too much and need to sub-divide the
problem.  Another guess is that actually
> you're running at a different rate than you think.  Be sure to measure
CLKOUT and verify according to the data sheet. 
> 
> To debug, suggest: 
> 
> 1) Make a small build, no DSP/BIOS, just main() function that doesn't do
much.  Maybe toggle a GPIO line. 
> 
> 2) Do not initialize SRAM, SDRAM, or any other peripheral attached to EMIF.
 Use only internal SRAM for the small test
> build. 
> 
> 3) Use 1.6V Vcc.  Don't go higher.  You should have several 0.1 uf and 0.01
uF decoupling caps on 1.6V.  Also you
> should have some large values (40 uF, 100 uF) on the Vcc rail, both near
the regulator and near the C5509A.  If not
> add more (chip caps).  Keep lead lengths super short (solder chip caps
together).  When the small code is running,
> there should *not* be any drop in Vcc or increase in ripple.  If there is,
you may have a V-regulator issue (or not
> enough decoupling). 
> 
> 4) Also measure 3.3V when the test code is running.  Same comments as 3)
apply. 
> 
> 5) Verify code runs at PLL multiplier 11-17 etc. 
> 
> Get this far, and report your results. 
> 
> If the above doesn't work but CLKOUT is correct at highest known-good PLL
multiplier, and Vcc's measure stable and
> correct value, then suggest pull off the 12 MHz crystal and dead-bug on a
12 MHz clock oscillator (or 12.288 or some
> approx value).  Use the existing crystal pads (XTAL1, XTAL2) and keep lead
lengths *very short* . 
> 
> -Jeff 
> 
>>
___________________________________________________________________________
>> 2. Do you have external memory attached?  If so is it SRAM orSDRAM? 
What if you decrease the PLL 
>>
>> Nearly everything :) : SRAM, FRAM, SDRAM, FLASH, NANDFLAS, four 3-state
multiplexer, ten or more logic gates, C5509A 
>>
>>
___________________________________________________________________________
>> 3.What if you decrease the PLL by one? 
>>
>> Actually in our lab works, we built ONE board (ıt is our first test
drive card). When we were sure that this card was
>> working properly we started to design our software based on 204MHz (Our
delays, timers, FFT processes etc) and sent
>> the card  to the serial production We encountered some reset
situations, some debug problems, software hangs problems
>> and started to investigate the core problem and looked nearly all of
the IC pins on board, the core voltage and IO
>> voltages on card, 12Mhz clock frequency. Everything is OK. Then I
changed the PLL frequency just to try and everything
>> was OK. So I started to decrease the PLL mult from 17 one by one. And I
see that pll mult : 10 is the minimum working
>> frequency of this card. Of course I could set this value below 10. But
I couldnt set it above 10. 
>>
>>
___________________________________________________________________________
>> 4. Did you try a clock oscillator input instead of crystal? 
>>
>> No I don't 
>>
>>
___________________________________________________________________________
>> 5.  Is this a 6-layer board?  4- layer? 
>>
>> Te board has 8 layers 
>>
>>
___________________________________________________________________________
>> 6. Regarding CLKOUT, if you're not using it, then why do you care
>> whether or not it is disabled? 
>>
>> I really don't care the CLKOUT. I could find only this information on
the internet that MITKO says in a topic. I think
>> he encountered the same problem. Because of that I want to ask if
someone know better than me about the CLKOUT 
>>
>>
___________________________________________________________________________
>> 7. Recommended Operating Conditions for this chip running at 200 MHz
>> specify a maximum of 1.65V, so why are you using 1.72V?  That could
>> cause problems in itself. 
>>
>> The main problem is not 200 Mhz  + 4 MHz. The main problem is I don't
want to run the C5509A on 120 MHz. It is a low
>> speed for the application. It can 180, 192, or 200 MHz.  But our card
can not exceed 120 MHz. I want to understand why
>> this is happening on our board. Every IC on board, EMIF interface, SPI
interfaces, CODEC interfaces, audio processes
>> are runnunig on 120MHz. But when I change it to the nearest high PLL
Mul: 11 It means 132 Mhz, the code hangs. ( I
>> tried all of the PLL Mult above 10) 
>>
>> Yes the core voltage is 1.6V. But in my opinion this core voltage is
another bench topic. Let me clear this. 
>>
>> ----When the cpu is in idle state I set the core voltage to 1.6V 
>>
>> ----When I encountered this ridicilious problem on PLL, I thought there
is a core voltage problem. So I measured the
>> core voltage, while the code was very active  process. I see that this
voltage was less than the idle core voltage. So
>> I adjusted the core voltage to 1.6V when the code is running. But with
this adjusment, idle core voltage is 1.714V. I
>> know it shouldn't exceed 1.65V but put yourself  to me if you have such
a ridicilious situtaion. 
>>
>>
___________________________________________________________________________
>> 8. Finally, if your firmware code sometimes hangs, how can you be sure
>> that it is not a software error?  I doubt that the PLL has any
problems. 
>>
>> Please see my comment on 3.
> 

Jeff Brower,
 I suggest you to check the core power supply. The core voltage should not 
change from 1.714V to 1.6V when  the code is running out of idle state. 
Higher working frequency consumes much more power.I think that your core 
supply power is not enough,or the power tracking problem.
                                JianJun
                                Best Regards

______________________________
New Code Sharing Section now Live on DSPRelated.com. Learn about the Reward Program for Contributors here.



(You need to be a member of c55x -- send a blank email to c55x-subscribe@yahoogroups.com )