Sign in

username:

password:



Not a member?

Search c55x



Search tips

Subscribe to c55x



c55x by Keywords

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

Ads

Discussion Groups

Discussion Groups | TMS320C55x | Re: Re: TMS320VC5509A EMIF problem (due to PLL unstability I guess)???

Technical discussions about the TI C55x DSPs (including the c5501, c5502, c5503, c5507, c5509, c5510 and OMAP5910).

  

Post a new Thread

Re: Re: TMS320VC5509A EMIF problem (due to PLL unstability I guess)??? - dpn...@dsp-bg.info - Jun 27 9:18:42 2006



Hi Michael,

Thank you for this information.
I think that there is a problem in the PLL design of C5509A.
It is good that I manage to get 186MHz  stable operation as I described.

Regards
Mitko

----- Original Message ----- 
From: "Michael Schuster" <s...@enertex.de>
To: <d...@dsp-bg.info>; <c...@yahoogroups.com>
Sent: Monday, June 26, 2006 5:05 PM
Subject: Re: [c55x] Re: TMS320VC5509A EMIF problem (due to PLL unstability I 
guess)???
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...@yahoogroups.com [mailto:c...@yahoogroups.com] On Behalf Of
> >>  d...@dsp-bg.info
> >>  Sent: Wednesday, June 21, 2006 9:41 AM
> >>  To: c...@yahoogroups.com
> >>  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
Geschäftsführer

Enertex Bayern GmbH
Innovative Systemlösungen der Energie- und Elektrotechnik
www.enertex.de

Erlachstraße 13           91301 Forchheim
Tel: ++49-9191-974 637 Fax: ++49-9191-974 687  Mob:0175 5151913

______________________________
New Year Gift for Members of DSPRelated.com.  Details here.


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