DSPRelated.com
Forums

C5502 EMIF question/help!

Started by amst...@ncsu.edu July 18, 2005
We designed a board based of the 5502, we have a SDRAM on CE0, and a ADC on
CE1. When we try and write a value to the address space of the ADC, the CE1 line
WONT drop. After closer inspection, CE0 wont drop either if a value is written
or read from its address space. Any suggestions on why our CE's are not working?



Alex-

> We designed a board based of the 5502, we have a SDRAM on CE0, and a ADC on
> CE1. When we try and write a value to the address space of the ADC, the CE1 line
> WONT drop. After closer inspection, CE0 wont drop either if a value is written
> or read from its address space. Any suggestions on why our CE's are not working?

One signal does not work: maybe a memory problem, such as EMIF registers not
configured correctly. Two signals don't work: maybe a whole chip problem. Did you
check CLKOUT rates? What if you toggle a GPIO line? Are you sure chip is running
normally?

-Jeff



Alex-

> We designed a board based of the 5502, we have a SDRAM on CE0, and a ADC on
> CE1. When we try and write a value to the address space of the ADC, the CE1 line
> WONT drop. After closer inspection, CE0 wont drop either if a value is written
> or read from its address space. Any suggestions on why our CE's are not working?

One signal does not work: maybe a memory problem, such as EMIF registers not
configured correctly. Two signals don't work: maybe a whole chip problem. Did you
check CLKOUT rates? What if you toggle a GPIO line? Are you sure chip is running
normally?

-Jeff



After moving the ADC to CE3 and leaving the SRAM at CE0 we
got CE3 to fall, and the ADC appears to be running as it should.
However our SRAM's CE line (CE0) still isnt working. We set a pointer
to its address space (just like we did for the ADC) and when we try
and read or write from it, the CE line WONT drop, however if the pointer
is in the ADC's address space, (CE3) it does drop..... Any suggestions?
-Alex > Alex-
>
>> We designed a board based of the 5502, we have a SDRAM on CE0, and a ADC
>> on
>> CE1. When we try and write a value to the address space of the ADC, the
>> CE1 line
>> WONT drop. After closer inspection, CE0 wont drop either if a value is
>> written
>> or read from its address space. Any suggestions on why our CE's are not
>> working?
>
> One signal does not work: maybe a memory problem, such as EMIF registers
> not
> configured correctly. Two signals don't work: maybe a whole chip
> problem. Did you
> check CLKOUT rates? What if you toggle a GPIO line? Are you sure chip is
> running
> normally?
>
> -Jeff
>




Alex-

> After moving the ADC to CE3 and leaving the SRAM at CE0 we
> got CE3 to fall, and the ADC appears to be running as it should.

Hey that's some progress, sounds exciting.

> However our SRAM's CE line (CE0) still isnt working. We set a pointer
> to its address space (just like we did for the ADC) and when we try
> and read or write from it, the CE line WONT drop, however if the pointer
> is in the ADC's address space, (CE3) it does drop..... Any suggestions?

What are your EMIF register settings? Are you using x32 or x16 configuration?
Another dumb question, but if you don't have SRAMs connected, then what does CE0 do?
Will it move then?

-Jeff

> > Alex-
> >
> >> We designed a board based of the 5502, we have a SDRAM on CE0, and a ADC
> >> on
> >> CE1. When we try and write a value to the address space of the ADC, the
> >> CE1 line
> >> WONT drop. After closer inspection, CE0 wont drop either if a value is
> >> written
> >> or read from its address space. Any suggestions on why our CE's are not
> >> working?
> >
> > One signal does not work: maybe a memory problem, such as EMIF registers
> > not
> > configured correctly. Two signals don't work: maybe a whole chip
> > problem. Did you
> > check CLKOUT rates? What if you toggle a GPIO line? Are you sure chip is
> > running
> > normally?
> >
> > -Jeff



We are using a x16 SDRAM. Here is our EMIF config struct:

EMIF_Config MyConfig = {
EMIF_GBLCTL1_DEFAULT, /* Uint16 gblctl1;*/
EMIF_GBLCTL2_DEFAULT, /* Uint16 gblctl2;*/
EMIF_CE1CTL1_DEFAULT, /* Uint16 ce1ctl1;*/
EMIF_CE1CTL2_DEFAULT, /* Uint16 ce1ctl2;*/
EMIF_CE0CTL1_RMK(EMIF_CE0CTL1_TA_OF(3),
EMIF_CE0CTL1_READ_STROBE_DEFAULT,
EMIF_CE0CTL1_MTYPE_16BIT_SDRAM,
EMIF_CE0CTL1_WRITE_HOLD_DEFAULT,
EMIF_CE0CTL1_READ_HOLD_DEFAULT), /* Uint16 ce0ctl1;*/
0xFFFFu, /* Uint16 ce0ctl2; */
EMIF_CE2CTL1_DEFAULT, /* Uint16 ce2ctl1; */
EMIF_CE2CTL2_DEFAULT, /* Uint16 ce2ctl2; */
EMIF_CE3CTL1_RMK(EMIF_CE3CTL1_TA_OF(3),
EMIF_CE3CTL1_READ_STROBE_DEFAULT,
EMIF_CE3CTL1_MTYPE_16BIT_ASYNC,
EMIF_CE3CTL1_WRITE_HOLD_DEFAULT,
EMIF_CE3CTL1_READ_HOLD_DEFAULT), /* Uint16 ce3ctl1*/
EMIF_CE3CTL2_DEFAULT, /* Uint16 ce3ctl2;*/
EMIF_SDCTL1_DEFAULT, /* Uint16 sdctl1;*/
0x69FFu, /* Uint16 sdctl2; */
EMIF_SDRFR1_DEFAULT, /* Uint16 sdrfr1; */
EMIF_SDRFR2_DEFAULT, /* Uint16 sdrfr2; */
EMIF_SDEXT1_DEFAULT, /* Uint16 sdext1; */
EMIF_SDEXT2_DEFAULT, /* Uint16 sdext2; */
EMIF_CE1SEC1_DEFAULT, /* Uint16 ce1sec1; */
EMIF_CE0SEC1_DEFAULT, /* Uint16 ce0sec1; */
EMIF_CE2SEC1_DEFAULT, /* Uint16 ce2sec1; */
EMIF_CE3SEC1_DEFAULT, /* Uint16 ce3sec1; */
0x0000u /* Uint16 cescr; */
}; Here is our command file:

MEMORY
{
MMR : o = 0x000000 l = 0x0000c0
DARAM0 : o = 0x0000C0 l = 0x001F3F
DARAM1 : o = 0x002000 l = 0x003FFF
/*
DARAM1 : o = 0x002000 l = 0x001FFF
DARAM2 : o = 0x004000 l = 0x001FFF
*/
DARAM3 : o = 0x006000 l = 0x001FFF
DARAM4 : o = 0x008000 l = 0x001FFF
DARAM5 : o = 0x00A000 l = 0x001FFF
DARAM6 : o = 0x00C000 l = 0x001FFF
DARAM7 : o = 0x00E000 l = 0x001FFF

CE0 : o = 0x010000 l = 0x3EFFFF
CE1 : o = 0x400000 l = 0x3FFFFF
CE2 : o = 0x800000 l = 0x3FFFFF
CE3 : o = 0xC00000 l = 0x3F7FFF
}

SECTIONS
{
.cinit > DARAM0
.text > DARAM1
.stack > DARAM0
.sysstack > DARAM0
.sysmem > DARAM3
.data > DARAM3
.cio > DARAM0
.bss > DARAM3
.const > DARAM0
.csldata > DARAM0
adc > CE3
mem > CE0
} We go about accessing our adc and memory by using some pragma's
to map some arrays to the CE spaces:

#pragma DATA_SECTION(adc1,"adc")
Uint32 adc1[100];

#pragma DATA_SECTION(test,"mem")
Uint32 test[100];

Then we simply read and write to either adc1 or test...
The odd thing is, when we read and write to adc1, CE3 DOES
drop, and everything works like it should. But reading and
writing to test, CE0 NEVER drops, however data seems to be
going somewhere, because we tried the following:
while(1) {
test[1] = 0xBEEF;
value = test[1];
}

watching value in the watch window, we see "BEEF" for a while,
then it will randomly switch to 0x00C2, and then back to BEEF.
But watching CE0 on a scope, it NEVER drops, so we are sure the
SRAM isnt storing the data, and the address of test is outside
of the DSP's internal address space... so where is BEEF coming from?
Any help or suggestions will be much appreciated!
-Alex > Alex-
>
>> After moving the ADC to CE3 and leaving the SRAM at CE0 we
>> got CE3 to fall, and the ADC appears to be running as it should.
>
> Hey that's some progress, sounds exciting.
>
>> However our SRAM's CE line (CE0) still isnt working. We set a pointer
>> to its address space (just like we did for the ADC) and when we try
>> and read or write from it, the CE line WONT drop, however if the pointer
>> is in the ADC's address space, (CE3) it does drop..... Any suggestions?
>
> What are your EMIF register settings? Are you using x32 or x16
> configuration?
> Another dumb question, but if you don't have SRAMs connected, then what
> does CE0 do

?
> Will it move then?
>
> -Jeff
>
>> > Alex-
>> >
>> >> We designed a board based of the 5502, we have a SDRAM on CE0, and a
>> ADC
>> >> on
>> >> CE1. When we try and write a value to the address space of the ADC,
>> the
>> >> CE1 line
>> >> WONT drop. After closer inspection, CE0 wont drop either if a value
>> is
>> >> written
>> >> or read from its address space. Any suggestions on why our CE's are
>> not
>> >> working?
>> >
>> > One signal does not work: maybe a memory problem, such as EMIF
>> registers
>> > not
>> > configured correctly. Two signals don't work: maybe a whole chip
>> > problem. Did you
>> > check CLKOUT rates? What if you toggle a GPIO line? Are you sure
>> chip is
>> > running
>> > normally?
>> >
>> > -Jeff
>



hi,

usually when interfacing C55x to SDRAM, we need to use
two CE spaces minimum. I am not sure how you have
managed with only one CE space.
Moreover, there are some EMIF registers which need to
be initialised specifically for SDRAM.
Please refer the doc at the following link:

http://focus.ti.com/lit/an/spra719/spra719.pdf

let me know if this helps..

regards,
Dileepan.

--- amstewa2@amst... wrote:

> We are using a x16 SDRAM. Here is our EMIF config
> struct:
>
> EMIF_Config MyConfig = {
> EMIF_GBLCTL1_DEFAULT, /* Uint16 gblctl1;*/
> EMIF_GBLCTL2_DEFAULT, /* Uint16 gblctl2;*/
> EMIF_CE1CTL1_DEFAULT, /* Uint16 ce1ctl1;*/
> EMIF_CE1CTL2_DEFAULT, /* Uint16 ce1ctl2;*/
> EMIF_CE0CTL1_RMK(EMIF_CE0CTL1_TA_OF(3),
> EMIF_CE0CTL1_READ_STROBE_DEFAULT,
> EMIF_CE0CTL1_MTYPE_16BIT_SDRAM,
> EMIF_CE0CTL1_WRITE_HOLD_DEFAULT,
> EMIF_CE0CTL1_READ_HOLD_DEFAULT), /* Uint16
> ce0ctl1;*/
> 0xFFFFu, /* Uint16 ce0ctl2; */
> EMIF_CE2CTL1_DEFAULT, /* Uint16 ce2ctl1; */
> EMIF_CE2CTL2_DEFAULT, /* Uint16 ce2ctl2; */
> EMIF_CE3CTL1_RMK(EMIF_CE3CTL1_TA_OF(3),
> EMIF_CE3CTL1_READ_STROBE_DEFAULT,
> EMIF_CE3CTL1_MTYPE_16BIT_ASYNC,
> EMIF_CE3CTL1_WRITE_HOLD_DEFAULT,
> EMIF_CE3CTL1_READ_HOLD_DEFAULT), /* Uint16
> ce3ctl1*/
> EMIF_CE3CTL2_DEFAULT, /* Uint16 ce3ctl2;*/
> EMIF_SDCTL1_DEFAULT, /* Uint16 sdctl1;*/
> 0x69FFu, /* Uint16 sdctl2; */
> EMIF_SDRFR1_DEFAULT, /* Uint16 sdrfr1; */
> EMIF_SDRFR2_DEFAULT, /* Uint16 sdrfr2; */
> EMIF_SDEXT1_DEFAULT, /* Uint16 sdext1; */
> EMIF_SDEXT2_DEFAULT, /* Uint16 sdext2; */
> EMIF_CE1SEC1_DEFAULT, /* Uint16 ce1sec1; */
> EMIF_CE0SEC1_DEFAULT, /* Uint16 ce0sec1; */
> EMIF_CE2SEC1_DEFAULT, /* Uint16 ce2sec1; */
> EMIF_CE3SEC1_DEFAULT, /* Uint16 ce3sec1; */
> 0x0000u /* Uint16 cescr; */
> }; > Here is our command file:
>
> MEMORY
> {
> MMR : o = 0x000000 l = 0x0000c0
> DARAM0 : o = 0x0000C0 l = 0x001F3F
> DARAM1 : o = 0x002000 l = 0x003FFF
> /*
> DARAM1 : o = 0x002000 l = 0x001FFF
> DARAM2 : o = 0x004000 l = 0x001FFF
> */
> DARAM3 : o = 0x006000 l = 0x001FFF
> DARAM4 : o = 0x008000 l = 0x001FFF
> DARAM5 : o = 0x00A000 l = 0x001FFF
> DARAM6 : o = 0x00C000 l = 0x001FFF
> DARAM7 : o = 0x00E000 l = 0x001FFF
>
> CE0 : o = 0x010000 l = 0x3EFFFF
> CE1 : o = 0x400000 l = 0x3FFFFF
> CE2 : o = 0x800000 l = 0x3FFFFF
> CE3 : o = 0xC00000 l = 0x3F7FFF
> }
>
> SECTIONS
> {
> .cinit > DARAM0
> .text > DARAM1
> .stack > DARAM0
> .sysstack > DARAM0
> .sysmem > DARAM3
> .data > DARAM3
> .cio > DARAM0
> .bss > DARAM3
> .const > DARAM0
> .csldata > DARAM0
> adc > CE3
> mem > CE0
> } > We go about accessing our adc and memory by using
> some pragma's
> to map some arrays to the CE spaces:
>
> #pragma DATA_SECTION(adc1,"adc")
> Uint32 adc1[100];
>
> #pragma DATA_SECTION(test,"mem")
> Uint32 test[100];
>
> Then we simply read and write to either adc1 or
> test...
> The odd thing is, when we read and write to adc1,
> CE3 DOES
> drop, and everything works like it should. But
> reading and
> writing to test, CE0 NEVER drops, however data seems
> to be
> going somewhere, because we tried the following:
> while(1) {
> test[1] = 0xBEEF;
> value = test[1];
> }
>
> watching value in the watch window, we see "BEEF"
> for a while,
> then it will randomly switch to 0x00C2, and then
> back to BEEF.
> But watching CE0 on a scope, it NEVER drops, so we
> are sure the
> SRAM isnt storing the data, and the address of test
> is outside
> of the DSP's internal address space... so where is
> BEEF coming from?
> Any help or suggestions will be much appreciated!
> -Alex > > Alex-
> >
> >> After moving the ADC to CE3 and leaving the SRAM
> at CE0 we
> >> got CE3 to fall, and the ADC appears to be
> running as it should.
> >
> > Hey that's some progress, sounds exciting.
> >
> >> However our SRAM's CE line (CE0) still isnt
> working. We set a pointer
> >> to its address space (just like we did for the
> ADC) and when we try
> >> and read or write from it, the CE line WONT drop,
> however if the pointer
> >> is in the ADC's address space, (CE3) it does
> drop..... Any suggestions?
> >
> > What are your EMIF register settings? Are you
> using x32 or x16
> > configuration?
> > Another dumb question, but if you don't have SRAMs
> connected, then what
> > does CE0 do
>
> ?
> > Will it move then?
> >
> > -Jeff
> >
> >> > Alex-
> >> >
> >> >> We designed a board based of the 5502, we have
> a SDRAM on CE0, and a
> >> ADC
> >> >> on
> >> >> CE1. When we try and write a value to the
> address space of the ADC,
> >> the
> >> >> CE1 line
> >> >> WONT drop. After closer inspection, CE0 wont
> drop either if a value
> >> is
> >> >> written
> >> >> or read from its address space. Any
> suggestions on why our CE's are
> >> not
> >> >> working?
> >> >
> >> > One signal does not work: maybe a memory
> problem, such as EMIF
> >> registers
> >> > not
> >> > configured correctly. Two signals don't work:
> maybe a whole chip
> >> > problem. Did you
> >> > check CLKOUT rates? What if you toggle a GPIO
> line? Are you sure
> >> chip is
> >> > running
> >> > normally?
> >> >
> >> > -Jeff
> >

____________________________________________________
Start your day with Yahoo! - make it your home page
http://www.yahoo.com/r/hs