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
clkmd problem. PLL, or core voltage may be
Started by ●November 12, 2009
Reply by ●November 12, 20092009-11-12
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
> 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
Reply by ●November 13, 20092009-11-13
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
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
Reply by ●November 13, 20092009-11-13
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.
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.
Reply by ●November 13, 20092009-11-13
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.
> 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.
Reply by ●November 16, 20092009-11-16
> 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
>
>> 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
