Hi,
were are running a c5503 at 200 MHz and an extern clock of 20 MHz, like this
---
#define CLKMD_VAL 0x2512 /* CPU clock = 10 * CLKIN */
#define SYSR_VAL 0x0007 /* CLKOUT = CPU clock / 10 */
void PLL_init(void)
{
CHIP_RSET(SYSR, SYSR_VAL);
PLL_RSET(CLKMD, CLKMD_VAL);
}
---
very stable.
l remember there is a 09-eval-kit, where the highest rate is 186 MHz (or
something). There might be a dependency with your problem.
BTW. We have tested 2 different devices, 260 MHz is possible...
Greetings,
Michael
Am Montag, 26. Juni 2006 10:13 schrieb d...@dsp-bg.info: > Hello All,
>
> My conclusions on the EMIF problems due to PLL instability:
>
> 1. The load on clockout pin influences the C5509A PLL stability
> significantly in case clockout signal is enabled (in both EBSR and ST3_55
> registers)!
>
> 2. In case clockout signal is disabled the load on clockout pin
doesn't
> influence the PLL stability anymore.
>
> 3. The EMIF of C5509A is not stable (at CPU clock around 200 MHz ) unless
> PLL_MULT is higer than 30. In this case to get acceptable CPU rate the
> PLL_DIV should be 1 so we have Fcpu=Fcrystal*PLL_MULT/2 and for example for
> Fcrystal=12Mhz and PLL_MULT=31 I got Fcpu=186Mhz. If I try to get the Fcpu
> around 200Mhz using PLL_DIV=0 and smaller value of PLL_MULT the EMIF is
> unstable.
>
> My conclusion: Alyaws use PLL_MULT as big as possible if you need EMIF of
> C5509A to work (at acceptable CPU speed).
>
> I will be very gratefully if someone tests the following code on his
> hardware. Just replace LED_ON/LED_OFF with some code to control a LED on
> your board. I think that that this loop will be stable only if the CPU is
> running on very low frequency <50Mhz or if PLL_MULT is > 30 (and therefore
> PLL_DIV=1).
>
> while(1){
> asm("\tMOV #25,*(#0x20000)"); // Write to external memory
>
> LED_ON;
>
> asm("\tMOV #125,*(#0x20001)"); // Write to external memory
>
> LED_OF;
> }
>
> Best Regards
> Mitko
> Andrej-
>
> >Your answer is great -- that must have been some debug battle to figure it
> > out. Just lab work, not in the docs, no obvious clues...
> >
> >It's gems like this that renew my faith in tech group collaboration.
I
> > can give 20 answers on the group, then to see one pop up like this is the
> > reward. Thanks.
> >
> >-Jeff
> >
> >Andrej Novak wrote:
> >> Hi Mitko,
> >>
> >> We had also hard time trying to make the 5509A working properly. We
> >> have been using
> >>
> >> 5509 for 4 years on few different devices and now we have switched to
> >> 5509A on all devices. We are
> >>
> >> using PLL initialization procedures in usb uploader, bootloader and
> >> firmware.
> >>
> >> The problem we had was the same as yours ? after some time the 5509A
> >> stops working! On 5509 this
> >>
> >> problem was not noticed.
> >>
> >> After several days of testing the conclusion was that the load on clock
> >> out pin could affect the processor stability.
> >>
> >> (on 5509 it was not possible to divide the system clk if the JTAG was
> >> disconnected - we have used hardware dividers).
> >>
> >> Our scheme characteristics (previous 5509A): clock out directly
> >> connected to 74lvc245 (Cl=4p; Rin=several Mohms.)
> >>
> >> After we have put a resistor in series (current version 5509A):
> >> clockout ? resistor 100R ? 74lvs245 the 5509a is working properly!
> >>
> >> Conclusion: Pay attention to clockout pin. Put in series a resistor.
> >> Higher resistance value will decrease the slopes
> >>
> >> (it depends also on your design ? Cload). Lower resistance could cause
> >> the malfunction of the PLL.
> >>
> >> Regards,
> >>
> >> Andrej Novak
> >>
> >> AGB Lab d.o.o.
> >>
> >> -----Original Message-----
> >> From: c... [mailto:c...] On Behalf Of
> >> d...@dsp-bg.info
> >> Sent: Wednesday, June 21, 2006 9:41 AM
> >> To: c...
> >> Subject: [c55x] TMS320VC5509A EMIF problem (due to PLL unstability I
> >> guess)???
> >>
> >> Hello All,
> >> I have a very hard time trying to make the EMIF in TMS320VC5509APGE-4A
> >> working stable at 192MHz.
> >>
> >> The test conditions:
> >>
> >> Hardware: DSP: TMS320VC5509APGE-4A
> >> Vdd=3.3V, Vcore=1.6V
> >> We have a supervisor which monitors Vdd, Vcore and manual reset button
> >> Crystal: 12 MHz,
> >> CPU works at 192 MHz
> >> LEDs on: GPIO0 - Green,
> >> GPIO1 - Red
> >> ARDY pin is pulled up using 2.2K
> >> On reset we put GPIO0=0, GPIO1=0, GPIO2=1, GPIO3=0
> >>
> >> 1. My initialization routine is:
> >>
> >> _c_int00: BSET ST1_INTM ; Init stack pointers
> >> AMOV #(STACK+STACK_SIZE),XSP
> >> AMOV #(SYSSTACK+STACK_SIZE),XSSP
> >>
> >> MOV #0000000000000111b,port(#0x07FD) ; SYSR (CLKOUT=CPU_CLK/14)
> >> MOV #1000001000000001b,port(#0x6C00) ; EBSR (Full EMIF, CLKOUT
> >> disabled)
> >> MOV #0000000000000000b,port(#0x0001) ; ICR (All domains active)
> >>
> >> MOV #RESETIV > > 8,mmap(IVPD); Init interrupt table pointers
> >> MOV #RESETIV > > 8,mmap(IVPH)
> >>
> >> MOV #0100100100000000b,mmap(ST1_55) ; Status registers
> >> MOV #1111000000000000b,mmap(ST2_55)
> >> MOV #0001110000000100b,mmap(ST3_55)
> >>
> >> MOV #00DFh,port(#3400h) ; GPIO - all outputs
> >> MOV #0000h,port(#3401h)
> >>
> >> MOV #0x0810,port(#0x1C00) ; CLKMD
> >> WAIT: BTST #0,port(#1C00h),TC1 ; Wait for PLL lock
> >> BCC WAIT,!TC1
> >>
> >> EMIRST_CFG ; Initialize EMIF (192 MHz)
> >> MOV #EMIRST_DATA,port(#EMIRST); Reset EMIF
> >>
> >> ; memfreq,wpe,memcen,nohold
> >> EGCR_CFG MEMFREQ_1BY16X,WPE_OFF,MEMCEN_OFF,ARDYOFF_ON
> >> MOV #EGCR_DATA,port(#EGCR) ; Global control register
> >>
> >> ; mtype,rdsetup,rdstrobe,rdhold
> >> CEx1_CFG ASYNC16,1,8,2
> >> ; rdexhld,wrexhld,wrsetup,wrstrobe,wrhold
> >> CEx2_CFG 0,0,1,3,2
> >> ; timeout
> >> CEx3_CFG 96
> >>
> >> 2. The problematic loop
> >>
> >> void main()
> >> {
> >> while(1){
> >> volatile ioport unsigned int *p;
> >>
> >> p = (volatile ioport unsigned int *)(0x3401);
> >>
> >> asm("\tMOV #25,*(#0x20000)"); // Write to external memory
> >> *p |= 0x0002; // Red on
> >> *p &= 0xFFFE; // Green off
> >>
> >> asm("\tMOV #125,*(#0x20001)"); // Write to external memory
> >> *p &= 0xFFFD; // Red off
> >> *p |= 0x0001; // Green on
> >> }
> >>
> >> }
> >>
> >> In the loop above I write in the external memory and toggle the RED and
> >> GREEN LEDs.
> >> After some time however (this time can be from 1sec up to several
> >> hours) the LEDs stop toggling.
> >> CE0 and AWR signals stop as well. It seems the program flow suddenly
> >> goes outside the loop.
> >>
> >> If we put LED toggling in the timer1 interrupt it continue normally so
> >> the DSP continue
> >> working but ouside the loop.
> >>
> >> All maskable interrupts are disabled. I have tried to put several
> >> NOPs in between of the instructions in the above loop but without any
> >> improvement.
> >> 0x20000 is just an example. The behavior is the same if other address
> >> from the external space is used.
> >>
> >> The problem stays the same if we remove the external periferal which we
> >> have at 0x20000 location. Note that we can read and write correctly
> >> from it. It is unstability problem.
> >>
> >> If internal address is used we don't observe this problem. I have
> >> experimented changing the time
> >> parameters of CE0 and AWR but again without success. I desperately need
> >> your help! Now I know almost
> >> the same about this problem as I knew 10 days ago (when I faced it).
> >>
> >> I have a feeling taht this is some EMIF problem due to PLL unstability?
> >>
> >> If you need more information just let me know. I can send you my test
> >> project as well.
> >> Kind Regards
> >>
> >> Mitko
> >> ---------------
> >> DSP forum from bulgaria
> >> www.dsp-bg.info
>
--
____________________________________________________
Dr.-Ing. Michael Schuster
Geschtsfrer
Enertex Bayern GmbH
Innovative Systemlungen der Energie- und Elektrotechnik
www.enertex.de
We have not had any stability problems with the 5509A DSPs we use in
several of our designs.
All of them are USB enabled, using a 12mhz crystal with a pllmult of 16
and plldiv of 0 (divide by 1), which equates to 192mhz.
We have designs that both use and don't use the clk out signal. On the
designs that do use it, it tends to be driving an input pin on a
SpartanIIE FPGA. A source termination resistor is normally added to
this signal for EMI purposes, however I don't recall having any
stability problems before adding one to the design either. We normally
have sdram hangin off the EMIF as well.
As far as the sample code provided, I have not tried it. I'd remind
anyone who does try it to initialize EMIF CE0 space before attempting
to. (in addition to other initializations of course. ;)
Have a good day,
Ryan
-----Original Message-----
From: c... [mailto:c...] On Behalf Of
d...@dsp-bg.info
Sent: June 26, 2006 2:13 AM
To: c...
Subject: [c55x] Re: TMS320VC5509A EMIF problem (due to PLL unstability I
guess)???
Hello All,
My conclusions on the EMIF problems due to PLL instability:
1. The load on clockout pin influences the C5509A PLL stability
significantly in case clockout signal is enabled (in both EBSR and
ST3_55 registers)!
2. In case clockout signal is disabled the load on clockout pin doesn't
influence the PLL stability anymore.
3. The EMIF of C5509A is not stable (at CPU clock around 200 MHz )
unless PLL_MULT is higer than 30.
In this case to get acceptable CPU rate the PLL_DIV should be 1 so we
have Fcpuystal*PLL_MULT/2 and for example for FcrystalMhz and
PLL_MULT1 I got Fcpu6Mhz. If I try to get the Fcpu around 200Mhz
using PLL_DIV=0 and smaller value of PLL_MULT the EMIF is unstable.
My conclusion: Alyaws use PLL_MULT as big as possible if you need EMIF
of C5509A to work (at acceptable CPU speed).
I will be very gratefully if someone tests the following code on his
hardware. Just replace LED_ON/LED_OFF with some code to control a LED on
your board. I think that that this loop will be stable only if the CPU
is running on very low frequency <50Mhz or if PLL_MULT is > 30 (and
therefore PLL_DIV=1).
while(1){
asm("\tMOV #25,*(#0x20000)"); // Write to external memory
LED_ON;
asm("\tMOV #125,*(#0x20001)"); // Write to external memory
LED_OF;
}
Best Regards
Mitko
Andrej- >
>Your answer is great -- that must have been some debug battle to figure it out. Just >lab work, not in the docs, no obvious clues...
>
>It's gems like this that renew my faith in tech group collaboration. I can give 20 >answers on the group, then to see one pop up like this
is the reward. Thanks. >
>-Jeff
>Andrej Novak wrote:
>
>> Hi Mitko,
>>
>> We had also hard time trying to make the 5509A working properly. We have been using >>
>> 5509 for 4 years on few different devices and now we have switched to 5509A on all >> devices. We are
>>
>> using PLL initialization procedures in usb uploader, bootloader and firmware. >>
>> The problem we had was the same as yours ? after some time the 5509A stops working! >> On 5509 this
>>
>> problem was not noticed.
>>
>> After several days of testing the conclusion was that the load on clock out pin >> could affect the processor stability.
>>
>> (on 5509 it was not possible to divide the system clk if the JTAG was disconnected >> - we have used hardware dividers).
>>
>> Our scheme characteristics (previous 5509A): clock out directly connected to >> 74lvc245 (Cl=4p; Rin=several Mohms.)
>>
>> After we have put a resistor in series (current version 5509A): clockout ? resistor >> 100R ? 74lvs245 the 5509a is working properly!
>>
>> Conclusion: Pay attention to clockout pin. Put in series a resistor. Higher >> resistance value will decrease the slopes
>>
>> (it depends also on your design ? Cload). Lower resistance could cause the >> malfunction of the PLL.
>>
>> Regards,
>>
>> Andrej Novak
>>
>> AGB Lab d.o.o.
>>
>> -----Original Message-----
>> From: c... [mailto:c...] On Behalf Of >> d...@dsp-bg.info
>> Sent: Wednesday, June 21, 2006 9:41 AM
>> To: c...
>> Subject: [c55x] TMS320VC5509A EMIF problem (due to PLL unstability I guess)??? >>
>> Hello All,
>> I have a very hard time trying to make the EMIF in TMS320VC5509APGE-4A >> working stable at 192MHz.
>>
>> The test conditions:
>>
>> Hardware: DSP: TMS320VC5509APGE-4A
>> Vdd=3.3V, Vcore=1.6V
>> We have a supervisor which monitors Vdd, Vcore and manual reset button >> Crystal: 12 MHz,
>> CPU works at 192 MHz
>> LEDs on: GPIO0 - Green,
>> GPIO1 - Red
>> ARDY pin is pulled up using 2.2K
>> On reset we put GPIO0=0, GPIO1=0, GPIO2=1, GPIO3=0
>>
>> 1. My initialization routine is:
>>
>> _c_int00: BSET ST1_INTM ; Init stack pointers
>> AMOV #(STACK+STACK_SIZE),XSP
>> AMOV #(SYSSTACK+STACK_SIZE),XSSP
>>
>> MOV #0000000000000111b,port(#0x07FD) ; SYSR (CLKOUT=CPU_CLK/14)
>> MOV #1000001000000001b,port(#0x6C00) ; EBSR (Full EMIF, CLKOUT
>> disabled)
>> MOV #0000000000000000b,port(#0x0001) ; ICR (All domains active)
>>
>> MOV #RESETIV > > 8,mmap(IVPD); Init interrupt table pointers
>> MOV #RESETIV > > 8,mmap(IVPH)
>>
>> MOV #0100100100000000b,mmap(ST1_55) ; Status registers
>> MOV #1111000000000000b,mmap(ST2_55)
>> MOV #0001110000000100b,mmap(ST3_55)
>>
>> MOV #00DFh,port(#3400h) ; GPIO - all outputs
>> MOV #0000h,port(#3401h)
>>
>> MOV #0x0810,port(#0x1C00) ; CLKMD
>> WAIT: BTST #0,port(#1C00h),TC1 ; Wait for PLL lock
>> BCC WAIT,!TC1
>>
>> EMIRST_CFG ; Initialize EMIF (192 MHz)
>> MOV #EMIRST_DATA,port(#EMIRST); Reset EMIF
>>
>> ; memfreq,wpe,memcen,nohold
>> EGCR_CFG MEMFREQ_1BY16X,WPE_OFF,MEMCEN_OFF,ARDYOFF_ON
>> MOV #EGCR_DATA,port(#EGCR) ; Global control register
>>
>> ; mtype,rdsetup,rdstrobe,rdhold
>> CEx1_CFG ASYNC16,1,8,2
>> ; rdexhld,wrexhld,wrsetup,wrstrobe,wrhold
>> CEx2_CFG 0,0,1,3,2
>> ; timeout
>> CEx3_CFG 96
>>
>> 2. The problematic loop
>>
>> void main()
>> {
>> while(1){
>> volatile ioport unsigned int *p;
>>
>> p = (volatile ioport unsigned int *)(0x3401);
>>
>> asm("\tMOV #25,*(#0x20000)"); // Write to external memory
>> *p |= 0x0002; // Red on
>> *p &= 0xFFFE; // Green off
>>
>> asm("\tMOV #125,*(#0x20001)"); // Write to external memory
>> *p &= 0xFFFD; // Red off
>> *p |= 0x0001; // Green on
>> }
>>
>> }
>>
>> In the loop above I write in the external memory and toggle the RED and >> GREEN LEDs.
>> After some time however (this time can be from 1sec up to several
>> hours) the LEDs stop toggling.
>> CE0 and AWR signals stop as well. It seems the program flow suddenly
>> goes outside the loop.
>>
>> If we put LED toggling in the timer1 interrupt it continue normally so >> the DSP continue
>> working but ouside the loop.
>>
>> All maskable interrupts are disabled. I have tried to put several
>> NOPs in between of the instructions in the above loop but without any >> improvement.
>> 0x20000 is just an example. The behavior is the same if other address >> from the external space is used.
>>
>> The problem stays the same if we remove the external periferal which we >> have at 0x20000 location. Note that we can read and
write correctly
>> from it. It is unstability problem.
>>
>> If internal address is used we don't observe this problem. I have
>> experimented changing the time
>> parameters of CE0 and AWR but again without success. I desperately need >> your help! Now I know almost
>> the same about this problem as I knew 10 days ago (when I faced it).
>>
>> I have a feeling taht this is some EMIF problem due to PLL unstability? >>
>> If you need more information just let me know. I can send you my test >> project as well.
>> Kind Regards
>>
>> Mitko
>> ---------------
>> DSP forum from bulgaria
>> www.dsp-bg.info
Reply by Jeff Brower●June 26, 20062006-06-26
Mitko-
Thanks for this good information.
We would test your code below for sure, but we're making only 5502 and
5510 boards, and not currently using 5509A. We decided against 5509
because a) no HPI without disabling other key interfaces, and b) due to
USB issues.
With 5502 we're running 300 MHz and EMIF (SRAM) at 100 MHz (I think,
have
to ask our engineers) and that seems to be stable. I wonder if the EMIF
issues you mention also exist on 5510...
-Jeff
> My conclusions on the EMIF problems due to PLL
instability:
>
> 1. The load on clockout pin influences the C5509A PLL stability
> significantly in case clockout signal is enabled (in both EBSR and ST3_55
> registers)!
>
> 2. In case clockout signal is disabled the load on clockout pin
doesn't
> influence the PLL stability anymore.
>
> 3. The EMIF of C5509A is not stable (at CPU clock around 200 MHz ) unless
> PLL_MULT is higer than 30.
> In this case to get acceptable CPU rate the PLL_DIV should be 1 so we
> have Fcpuystal*PLL_MULT/2 and for example for FcrystalMhz and
> PLL_MULT1 I got Fcpu6Mhz. If I try to get the Fcpu around 200Mhz
> using PLL_DIV=0 and smaller value of PLL_MULT the EMIF is unstable.
>
> My conclusion: Alyaws use PLL_MULT as big as possible if you need EMIF of
> C5509A to work (at acceptable CPU speed).
>
> I will be very gratefully if someone tests the following code on his
> hardware. Just replace LED_ON/LED_OFF with some code to control a LED on
> your board. I think that that this loop will be stable only if the CPU is
> running on very low frequency <50Mhz or if PLL_MULT is > 30 (and
> therefore PLL_DIV=1).
>
> while(1){
> asm("\tMOV #25,*(#0x20000)"); // Write to external memory
>
> LED_ON;
>
> asm("\tMOV #125,*(#0x20001)"); // Write to external memory
>
> LED_OF;
> }
>
> Best Regards
> Mitko
> Andrej-
>>
>>Your answer is great -- that must have been some debug battle to figure
>> it out. Just
>>lab work, not in the docs, no obvious clues...
>>
>>It's gems like this that renew my faith in tech group collaboration.
I
>> can give 20
>>answers on the group, then to see one pop up like this is the reward.
>> Thanks.
>>
>>-Jeff
>>Andrej Novak wrote:
>>
>>> Hi Mitko,
>>>
>>> We had also hard time trying to make the 5509A working properly. We
>>> have been using
>>>
>>> 5509 for 4 years on few different devices and now we have switched to
>>> 5509A on all
>>> devices. We are
>>>
>>> using PLL initialization procedures in usb uploader, bootloader and
>>> firmware.
>>>
>>> The problem we had was the same as yours ? after some time the 5509A
>>> stops working!
>>> On 5509 this
>>>
>>> problem was not noticed.
>>>
>>> After several days of testing the conclusion was that the load on
>>> clock out pin
>>> could affect the processor stability.
>>>
>>> (on 5509 it was not possible to divide the system clk if the JTAG was
>>> disconnected
>>> - we have used hardware dividers).
>>>
>>> Our scheme characteristics (previous 5509A): clock out directly
>>> connected to
>>> 74lvc245 (Cl=4p; Rin=several Mohms.)
>>>
>>> After we have put a resistor in series (current version 5509A):
>>> clockout ? resistor
>>> 100R ? 74lvs245 the 5509a is working properly!
>>>
>>> Conclusion: Pay attention to clockout pin. Put in series a resistor.
>>> Higher
>>> resistance value will decrease the slopes
>>>
>>> (it depends also on your design ? Cload). Lower resistance could cause
>>> the
>>> malfunction of the PLL.
>>>
>>> Regards,
>>>
>>> Andrej Novak
>>>
>>> AGB Lab d.o.o.
>>>
>>> -----Original Message-----
>>> From: c... [mailto:c...] On Behalf Of
>>> d...@dsp-bg.info
>>> Sent: Wednesday, June 21, 2006 9:41 AM
>>> To: c...
>>> Subject: [c55x] TMS320VC5509A EMIF problem (due to PLL unstability I
>>> guess)???
>>>
>>> Hello All,
>>> I have a very hard time trying to make the EMIF in TMS320VC5509APGE-4A
>>> working stable at 192MHz.
>>>
>>> The test conditions:
>>>
>>> Hardware: DSP: TMS320VC5509APGE-4A
>>> Vdd=3.3V, Vcore=1.6V
>>> We have a supervisor which monitors Vdd, Vcore and manual reset button
>>> Crystal: 12 MHz,
>>> CPU works at 192 MHz
>>> LEDs on: GPIO0 - Green,
>>> GPIO1 - Red
>>> ARDY pin is pulled up using 2.2K
>>> On reset we put GPIO0=0, GPIO1=0, GPIO2=1, GPIO3=0
>>>
>>> 1. My initialization routine is:
>>>
>>> _c_int00: BSET ST1_INTM ; Init stack pointers
>>> AMOV #(STACK+STACK_SIZE),XSP
>>> AMOV #(SYSSTACK+STACK_SIZE),XSSP
>>>
>>> MOV #0000000000000111b,port(#0x07FD) ; SYSR (CLKOUT=CPU_CLK/14)
>>> MOV #1000001000000001b,port(#0x6C00) ; EBSR (Full EMIF, CLKOUT
>>> disabled)
>>> MOV #0000000000000000b,port(#0x0001) ; ICR (All domains active)
>>>
>>> MOV #RESETIV > > 8,mmap(IVPD); Init interrupt table pointers
>>> MOV #RESETIV > > 8,mmap(IVPH)
>>>
>>> MOV #0100100100000000b,mmap(ST1_55) ; Status registers
>>> MOV #1111000000000000b,mmap(ST2_55)
>>> MOV #0001110000000100b,mmap(ST3_55)
>>>
>>> MOV #00DFh,port(#3400h) ; GPIO - all outputs
>>> MOV #0000h,port(#3401h)
>>>
>>> MOV #0x0810,port(#0x1C00) ; CLKMD
>>> WAIT: BTST #0,port(#1C00h),TC1 ; Wait for PLL lock
>>> BCC WAIT,!TC1
>>>
>>> EMIRST_CFG ; Initialize EMIF (192 MHz)
>>> MOV #EMIRST_DATA,port(#EMIRST); Reset EMIF
>>>
>>> ; memfreq,wpe,memcen,nohold
>>> EGCR_CFG MEMFREQ_1BY16X,WPE_OFF,MEMCEN_OFF,ARDYOFF_ON
>>> MOV #EGCR_DATA,port(#EGCR) ; Global control register
>>>
>>> ; mtype,rdsetup,rdstrobe,rdhold
>>> CEx1_CFG ASYNC16,1,8,2
>>> ; rdexhld,wrexhld,wrsetup,wrstrobe,wrhold
>>> CEx2_CFG 0,0,1,3,2
>>> ; timeout
>>> CEx3_CFG 96
>>>
>>> 2. The problematic loop
>>>
>>> void main()
>>> {
>>> while(1){
>>> volatile ioport unsigned int *p;
>>>
>>> p = (volatile ioport unsigned int *)(0x3401);
>>>
>>> asm("\tMOV #25,*(#0x20000)"); // Write to external memory
>>> *p |= 0x0002; // Red on
>>> *p &= 0xFFFE; // Green off
>>>
>>> asm("\tMOV #125,*(#0x20001)"); // Write to external memory
>>> *p &= 0xFFFD; // Red off
>>> *p |= 0x0001; // Green on
>>> }
>>>
>>> }
>>>
>>> In the loop above I write in the external memory and toggle the RED
>>> and
>>> GREEN LEDs.
>>> After some time however (this time can be from 1sec up to several
>>> hours) the LEDs stop toggling.
>>> CE0 and AWR signals stop as well. It seems the program flow suddenly
>>> goes outside the loop.
>>>
>>> If we put LED toggling in the timer1 interrupt it continue normally so
>>> the DSP continue
>>> working but ouside the loop.
>>>
>>> All maskable interrupts are disabled. I have tried to put several
>>> NOPs in between of the instructions in the above loop but without any
>>> improvement.
>>> 0x20000 is just an example. The behavior is the same if other address
>>> from the external space is used.
>>>
>>> The problem stays the same if we remove the external periferal which
>>> we
>>> have at 0x20000 location. Note that we can read and write correctly
>>> from it. It is unstability problem.
>>>
>>> If internal address is used we don't observe this problem. I have
>>> experimented changing the time
>>> parameters of CE0 and AWR but again without success. I desperately
>>> need
>>> your help! Now I know almost
>>> the same about this problem as I knew 10 days ago (when I faced it).
>>>
>>> I have a feeling taht this is some EMIF problem due to PLL
>>> unstability?
>>>
>>> If you need more information just let me know. I can send you my test
>>> project as well.
>>> Kind Regards
>>>
>>> Mitko
>>> ---------------
>>> DSP forum from bulgaria
>>> www.dsp-bg.info
Reply by dpn...@dsp-bg.info●June 26, 20062006-06-26
Hello All,
My conclusions on the EMIF problems due to PLL instability:
1. The load on clockout pin influences the C5509A PLL stability significantly in
case clockout signal is enabled (in both EBSR and ST3_55 registers)!
2. In case clockout signal is disabled the load on clockout pin doesn't
influence the PLL stability anymore.
3. The EMIF of C5509A is not stable (at CPU clock around 200 MHz ) unless
PLL_MULT is higer than 30.
In this case to get acceptable CPU rate the PLL_DIV should be 1 so we have
Fcpuystal*PLL_MULT/2 and for example for FcrystalMhz and PLL_MULT1 I got
Fcpu6Mhz. If I try to get the Fcpu around 200Mhz using PLL_DIV=0 and smaller
value of PLL_MULT the EMIF is unstable.
My conclusion: Alyaws use PLL_MULT as big as possible if you need EMIF of C5509A
to work (at acceptable CPU speed).
I will be very gratefully if someone tests the following code on his hardware.
Just replace LED_ON/LED_OFF with some code to control a LED on your board. I
think that that this loop will be stable only if the CPU is running on very low
frequency <50Mhz or if PLL_MULT is > 30 (and therefore PLL_DIV=1).
while(1){
asm("\tMOV #25,*(#0x20000)"); // Write to external memory
LED_ON;
asm("\tMOV #125,*(#0x20001)"); // Write to external memory
LED_OF;
}
Best Regards
Mitko
Andrej- >
>Your answer is great -- that must have been some debug battle to figure it out.
Just
>lab work, not in the docs, no obvious clues...
>
>It's gems like this that renew my faith in tech group collaboration. I
can give 20
>answers on the group, then to see one pop up like this is the reward.
Thanks.
>
>-Jeff
>Andrej Novak wrote:
>
>> Hi Mitko,
>>
>> We had also hard time trying to make the 5509A working properly. We have
been using
>>
>> 5509 for 4 years on few different devices and now we have switched to 5509A
on all
>> devices. We are
>>
>> using PLL initialization procedures in usb uploader, bootloader and
firmware.
>>
>> The problem we had was the same as yours ? after some time the 5509A stops
working!
>> On 5509 this
>>
>> problem was not noticed.
>>
>> After several days of testing the conclusion was that the load on clock out
pin
>> could affect the processor stability.
>>
>> (on 5509 it was not possible to divide the system clk if the JTAG was
disconnected
>> - we have used hardware dividers).
>>
>> Our scheme characteristics (previous 5509A): clock out directly connected
to
>> 74lvc245 (Cl=4p; Rin=several Mohms.)
>>
>> After we have put a resistor in series (current version 5509A): clockout ?
resistor
>> 100R ? 74lvs245 the 5509a is working properly!
>>
>> Conclusion: Pay attention to clockout pin. Put in series a resistor.
Higher
>> resistance value will decrease the slopes
>>
>> (it depends also on your design ? Cload). Lower resistance could cause
the
>> malfunction of the PLL.
>>
>> Regards,
>>
>> Andrej Novak
>>
>> AGB Lab d.o.o.
>>
>> -----Original Message-----
>> From: c... [mailto:c...] On Behalf Of
>> d...@dsp-bg.info
>> Sent: Wednesday, June 21, 2006 9:41 AM
>> To: c...
>> Subject: [c55x] TMS320VC5509A EMIF problem (due to PLL unstability I
guess)???
>>
>> Hello All,
>> I have a very hard time trying to make the EMIF in TMS320VC5509APGE-4A
>> working stable at 192MHz.
>>
>> The test conditions:
>>
>> Hardware: DSP: TMS320VC5509APGE-4A
>> Vdd=3.3V, Vcore=1.6V
>> We have a supervisor which monitors Vdd, Vcore and manual reset button
>> Crystal: 12 MHz,
>> CPU works at 192 MHz
>> LEDs on: GPIO0 - Green,
>> GPIO1 - Red
>> ARDY pin is pulled up using 2.2K
>> On reset we put GPIO0=0, GPIO1=0, GPIO2=1, GPIO3=0
>>
>> 1. My initialization routine is:
>>
>> _c_int00: BSET ST1_INTM ; Init stack pointers
>> AMOV #(STACK+STACK_SIZE),XSP
>> AMOV #(SYSSTACK+STACK_SIZE),XSSP
>>
>> MOV #0000000000000111b,port(#0x07FD) ; SYSR (CLKOUT=CPU_CLK/14)
>> MOV #1000001000000001b,port(#0x6C00) ; EBSR (Full EMIF, CLKOUT
>> disabled)
>> MOV #0000000000000000b,port(#0x0001) ; ICR (All domains active)
>>
>> MOV #RESETIV > > 8,mmap(IVPD); Init interrupt table pointers
>> MOV #RESETIV > > 8,mmap(IVPH)
>>
>> MOV #0100100100000000b,mmap(ST1_55) ; Status registers
>> MOV #1111000000000000b,mmap(ST2_55)
>> MOV #0001110000000100b,mmap(ST3_55)
>>
>> MOV #00DFh,port(#3400h) ; GPIO - all outputs
>> MOV #0000h,port(#3401h)
>>
>> MOV #0x0810,port(#0x1C00) ; CLKMD
>> WAIT: BTST #0,port(#1C00h),TC1 ; Wait for PLL lock
>> BCC WAIT,!TC1
>>
>> EMIRST_CFG ; Initialize EMIF (192 MHz)
>> MOV #EMIRST_DATA,port(#EMIRST); Reset EMIF
>>
>> ; memfreq,wpe,memcen,nohold
>> EGCR_CFG MEMFREQ_1BY16X,WPE_OFF,MEMCEN_OFF,ARDYOFF_ON
>> MOV #EGCR_DATA,port(#EGCR) ; Global control register
>>
>> ; mtype,rdsetup,rdstrobe,rdhold
>> CEx1_CFG ASYNC16,1,8,2
>> ; rdexhld,wrexhld,wrsetup,wrstrobe,wrhold
>> CEx2_CFG 0,0,1,3,2
>> ; timeout
>> CEx3_CFG 96
>>
>> 2. The problematic loop
>>
>> void main()
>> {
>> while(1){
>> volatile ioport unsigned int *p;
>>
>> p = (volatile ioport unsigned int *)(0x3401);
>>
>> asm("\tMOV #25,*(#0x20000)"); // Write to external memory
>> *p |= 0x0002; // Red on
>> *p &= 0xFFFE; // Green off
>>
>> asm("\tMOV #125,*(#0x20001)"); // Write to external memory
>> *p &= 0xFFFD; // Red off
>> *p |= 0x0001; // Green on
>> }
>>
>> }
>>
>> In the loop above I write in the external memory and toggle the RED and
>> GREEN LEDs.
>> After some time however (this time can be from 1sec up to several
>> hours) the LEDs stop toggling.
>> CE0 and AWR signals stop as well. It seems the program flow suddenly
>> goes outside the loop.
>>
>> If we put LED toggling in the timer1 interrupt it continue normally so
>> the DSP continue
>> working but ouside the loop.
>>
>> All maskable interrupts are disabled. I have tried to put several
>> NOPs in between of the instructions in the above loop but without any
>> improvement.
>> 0x20000 is just an example. The behavior is the same if other address
>> from the external space is used.
>>
>> The problem stays the same if we remove the external periferal which we
>> have at 0x20000 location. Note that we can read and write correctly
>> from it. It is unstability problem.
>>
>> If internal address is used we don't observe this problem. I have
>> experimented changing the time
>> parameters of CE0 and AWR but again without success. I desperately need
>> your help! Now I know almost
>> the same about this problem as I knew 10 days ago (when I faced it).
>>
>> I have a feeling taht this is some EMIF problem due to PLL unstability?
>>
>> If you need more information just let me know. I can send you my test
>> project as well.
>> Kind Regards
>>
>> Mitko
>> ---------------
>> DSP forum from bulgaria
>> www.dsp-bg.info