problem while executing program from external SDRAM

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From English to

Threaded View
Hi all,

I made a board using sharp LH79520 and micron sdram 8MB and flash
memory.

I made a boot loader (running from the flash) which is just putting the
binary image (made by the crossworks IDE) into the SDRAM.

Now the problem is that program code is written and verified properly
in the SDRAM but while execution the program hangs abruptly at random
execution points, and the values of debugging variables are not
consistent across runs (variables take on values which appear corrupted
eg: negetive values when positive are expected). The same program
executes properly when run in the 32KB internal ram.

The SDRAM is not accesible through JTAG and so the debugging is being
done through the serial port and so I cannot access the memory
locations directly.

Any solutions or pointers to resolve this problem?

Thanks in advance,

Aditya


Re: problem while executing program from external SDRAM


Quoted text here. Click to load it

Did you copy every section in SDRAM, code and initialized variables?


Re: problem while executing program from external SDRAM
Quoted text here. Click to load it

I don't know the architecture you are using, but probably you will have
to instruct compiler/linker to generate code in appropriate memory
space, in your case RAM, then copy code from flash into that location.
Otherwise your variable references may be off (depending how code is
generated).

Maciek.

Re: problem while executing program from external SDRAM
@Sawik
I had changed the memory map in the compiler options to reflect the
final destination of the code. (I may be wrong but without that I dont
think the program would even go beyond the initialisation stages as
function calls need stacks in the proper places).

I am somewhat a beginner so will describe in detail what all I have
done to make sure I am not missing something obvious.

The controller is LH79520 ARM7TDMI based controller.

 My boot loader is very simplistic.What it is doing is just copy the
binary file coming over the serial port to appropriate memory location
in SDRAM, verify if it has been copied correctly (by reading the image
from the sdram and putting it back on the serial port so that the pc
can compare the two binary files ), and pass control to the specified
location.

@Lanarcam
I did not initialise the variables AFTER copying the code to SDRAM. How
do you do that? Why do you need to do that? Should not the binary image
generated by the compiler/linker handle any initialisations?
Downloading the same program to the internal SRAM through JTAG works,
so are extra initialisations needed for SDRAM?

I tried putting in a few dummy statements and some nops, and the
program seems to work correctly for some time (has correct variable
values) but it also hangs all the same after some time (the point at
which it hangs is different for evry run). Is this a problem with
aligning the code?

The program is accessing a MMC card using the SPI mode. I dont think
the problem is with the program, because as I said earlier, it works
correctly from the SRAM.

Lanarcam and Sawik, thanks for the prompt replies.

Any further pointers or solutions are welcome.

Thanks
-Aditya


Re: problem while executing program from external SDRAM


Quoted text here. Click to load it

Your linker will probably generate at least two sections that
need to be copied into DRAM, the code section and the
initialized variables section.

You should find the addresses of these sections in the map
file generated by the linker.

Can you can verify that you find the correct values for your
variables in SDRAM through JTAG?

What you could do is write a simple programm with a few
initialized variables and just a loop in the main function
that outputs their values on some device, perhaps a
serial port.

Quoted text here. Click to load it

How does it "hang" ?

You could also try to put infinite loops at different places in
your code, and see if your program reaches them.

Quoted text here. Click to load it


Re: problem while executing program from external SDRAM
<memory corruption>

Quoted text here. Click to load it

Make sure you are zeroing the uninitialized data segment.

--
"I'm mad as hell, and I'm probably going to just sit here and take it!"

Re: problem while executing program from external SDRAM

Quoted text here. Click to load it

Could it be a refresh problem ? This would be consistent with erratic behaviour.

Have you tried running the whole thing at a slower clock to eliminate marginal
timings as a
potential problem ?


Re: problem while executing program from external SDRAM
Will try reducing the clock speed.
I had thought about this but did not try it out as I thought that since
the boot loader can read and write from the SDRAM the SDRAM should be
working correctly. Also all printf's etc are given on the serial port
without any problem, it is the variables and arrays that primarily have
the problem.

BTW by 'the whole thing' do you mean reducing the controller clock as
well as the SDRAM clock or just the SDRAM clock?

Will let you know what happens with reduced clock speed.

Thanks for the suggestion.

Aditya


Mike Harrison wrote:

Quoted text here. Click to load it
behaviour.
Quoted text here. Click to load it
timings as a
Quoted text here. Click to load it


Re: problem while executing program from external SDRAM
Quoted text here. Click to load it

I'd be inclined to write a memory tester and thoroughly test the integrity
of the SDRAM space before entrusting data, let alone code, to it. Yell if
you need an example: I have one that isn't fast, but is thorough.

Other thoughts:
 - I assume that your copied code ends up running at the memory location it
expected at compile time. If not, I wouldn't expect it to run at all.
 - Could it be a stack issue? Where is the stack? Is it big enough?
 - Does your SDRAM have good decoupling?

Steve
http://www.fivetrees.com



Re: problem while executing program from external SDRAM
On Fri, 17 Jun 2005 02:05:01 +0100, "Steve at fivetrees"

Quoted text here. Click to load it

You should also ensure it tests refresh functionality, remembering that normal
access will refresh
as a side-effect, and thet refresh specs tend to be very conservative so you
should wait several
seconds between writing and reading back, and if possible avoid external access
while waiting (e.g.
sleep mode or run from internal RAM/cache)

The OPs comments about 'random' failures would put refresh issues fairly high on
the list of
suspects.


Site Timeline