Dear Experts,
I have designed a board which has a DM640 interfaced to Micron SDRAM
MT48LC4M32B2.
My problem is that if I do a write and readback from my SDRAM using unsigned
int pointers, then the readback works ok. If I instead do the readback using
unsigned char pointers, then the readback doesn't work. The data is
apparently not being written correctly in this case as checked through View-
Memory also.
Our observation is that the .far & .cinit sections of programs need to be in
internal memory for the programs to work. Could this be related to the above
problem?
Does anyone have any hints as to the cause or solution of this problem?
I have appended the test programs below:
Unsigned int program that worked ( for loop ran completely without
breaking):
main()
{
int correctWriteRead=0;
unsigned int *ptr;
for(ptr = (unsigned int *)0x80000000; ptr<(unsigned int *)0x80FFFFFF; ptr++)
{
*ptr = 0xFFABCDEF;
if(*ptr == 0xFFABCDEF)
{ correctWriteRead++;
}
else
{
break;
}
}
return 0;
}
Unsigned char program that did not work ( broke out of loop in the 1st
iteration itself)
main()
{
int correctWriteRead=0;
unsigned char *ptr;
for(ptr = (unsigned char *)0x80000000; ptr<(unsigned char *)0x80FFFFFF;
ptr++)
{
*ptr = 0xAB;
if(*ptr == 0xAB)
{ correctWriteRead++;
}
else
{
break;
}
}
return 0;
}
Thanks in advance!
Anand
Problem with single byte access to SDRAM
Started by ●September 7, 2006
Reply by ●September 8, 20062006-09-08
Anand,
> My problem is that if I do a write and readback from my SDRAM using
> unsigned
> int pointers, then the readback works ok. If I instead do the readback
> using
> unsigned char pointers, then the readback doesn't work. The data is
> apparently not being written correctly in this case as checked through
> View-
> Memory also.
Using unigned int, you do the access on whole 32 bit of the DM640's EMIF.
Using byte access, ... you don't
So it looks like your issue is related to byte-enable control.
Did you connected correctly the byte-enable control from DSP EMIF
to the correct memory chip ?
Jean-Michel.
> My problem is that if I do a write and readback from my SDRAM using
> unsigned
> int pointers, then the readback works ok. If I instead do the readback
> using
> unsigned char pointers, then the readback doesn't work. The data is
> apparently not being written correctly in this case as checked through
> View-
> Memory also.
Using unigned int, you do the access on whole 32 bit of the DM640's EMIF.
Using byte access, ... you don't
So it looks like your issue is related to byte-enable control.
Did you connected correctly the byte-enable control from DSP EMIF
to the correct memory chip ?
Jean-Michel.
Reply by ●September 8, 20062006-09-08
Anand-
> I have designed a board which has a DM640 interfaced to Micron SDRAM
> MT48LC4M32B2.
>
> My problem is that if I do a write and readback from my SDRAM using unsigned
> int pointers, then the readback works ok. If I instead do the readback using
> unsigned char pointers, then the readback doesn't work. The data is
> apparently not being written correctly in this case as checked through View-
> Memory also.
Do you have a .gel file to initiaize SDRAM from CCS? If you use CCS to initialize
SDRAM with zero, then change one byte, what happens? If you initialize to zero, then
run your test char program below, what does CCS say the first 32-bit memory value
looks like? Is 0xAB in the first byte and junk in other bytes? 0xAB does not appear
at all?
> Our observation is that the .far & .cinit sections of programs need to be in
> internal memory for the programs to work. Could this be related to the above
> problem?
Yes could be -- if SRAM interface is not working yet, then code instructions would
fail also.
> Does anyone have any hints as to the cause or solution of this problem?
First, did you rule out a software problem or misunderstanding by performing the
*exact same* test using internal memory? I.e. just change the pointer value?
Second, have you checked byte-enable signals on your SDRAM? If one of those lines is
missing or something is wrong with those signals on your prototype board (maybe
series R-pack not soldered well for example) then it could explain it. Also make
sure your SDRAM config registers are set for correct word width.
> I have appended the test programs below:
Also suggest to use 'volatile' keyword in your tests:
unsigned volatile int* ptr;
-Jeff
> Unsigned int program that worked ( for loop ran completely without
> breaking):
>
> main()
>
> {
>
> int correctWriteRead=0;
>
> unsigned int *ptr;
>
> for(ptr = (unsigned int *)0x80000000; ptr<(unsigned int *)0x80FFFFFF; ptr++)
>
> {
>
> *ptr = 0xFFABCDEF;
>
> if(*ptr == 0xFFABCDEF)
>
> { correctWriteRead++;
>
> }
>
> else
>
> {
>
> break;
>
> }
>
> }
>
> return 0;
>
> }
>
> Unsigned char program that did not work ( broke out of loop in the 1st
> iteration itself)
>
> main()
>
> {
>
> int correctWriteRead=0;
>
> unsigned char *ptr;
>
> for(ptr = (unsigned char *)0x80000000; ptr<(unsigned char *)0x80FFFFFF;
> ptr++)
>
> {
>
> *ptr = 0xAB;
>
> if(*ptr == 0xAB)
>
> { correctWriteRead++;
>
> }
>
> else
>
> {
>
> break;
>
> }
>
> }
>
> return 0;
>
> }
>
> Thanks in advance!
> I have designed a board which has a DM640 interfaced to Micron SDRAM
> MT48LC4M32B2.
>
> My problem is that if I do a write and readback from my SDRAM using unsigned
> int pointers, then the readback works ok. If I instead do the readback using
> unsigned char pointers, then the readback doesn't work. The data is
> apparently not being written correctly in this case as checked through View-
> Memory also.
Do you have a .gel file to initiaize SDRAM from CCS? If you use CCS to initialize
SDRAM with zero, then change one byte, what happens? If you initialize to zero, then
run your test char program below, what does CCS say the first 32-bit memory value
looks like? Is 0xAB in the first byte and junk in other bytes? 0xAB does not appear
at all?
> Our observation is that the .far & .cinit sections of programs need to be in
> internal memory for the programs to work. Could this be related to the above
> problem?
Yes could be -- if SRAM interface is not working yet, then code instructions would
fail also.
> Does anyone have any hints as to the cause or solution of this problem?
First, did you rule out a software problem or misunderstanding by performing the
*exact same* test using internal memory? I.e. just change the pointer value?
Second, have you checked byte-enable signals on your SDRAM? If one of those lines is
missing or something is wrong with those signals on your prototype board (maybe
series R-pack not soldered well for example) then it could explain it. Also make
sure your SDRAM config registers are set for correct word width.
> I have appended the test programs below:
Also suggest to use 'volatile' keyword in your tests:
unsigned volatile int* ptr;
-Jeff
> Unsigned int program that worked ( for loop ran completely without
> breaking):
>
> main()
>
> {
>
> int correctWriteRead=0;
>
> unsigned int *ptr;
>
> for(ptr = (unsigned int *)0x80000000; ptr<(unsigned int *)0x80FFFFFF; ptr++)
>
> {
>
> *ptr = 0xFFABCDEF;
>
> if(*ptr == 0xFFABCDEF)
>
> { correctWriteRead++;
>
> }
>
> else
>
> {
>
> break;
>
> }
>
> }
>
> return 0;
>
> }
>
> Unsigned char program that did not work ( broke out of loop in the 1st
> iteration itself)
>
> main()
>
> {
>
> int correctWriteRead=0;
>
> unsigned char *ptr;
>
> for(ptr = (unsigned char *)0x80000000; ptr<(unsigned char *)0x80FFFFFF;
> ptr++)
>
> {
>
> *ptr = 0xAB;
>
> if(*ptr == 0xAB)
>
> { correctWriteRead++;
>
> }
>
> else
>
> {
>
> break;
>
> }
>
> }
>
> return 0;
>
> }
>
> Thanks in advance!
