EmbeddedRelated.com
Forums

problem while executing program from external SDRAM

Started by aditya June 16, 2005
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


aditya wrote:
> 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?
Did you copy every section in SDRAM, code and initialized variables?
aditya wrote:
> 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 >
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.
@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

On Thu, 16 Jun 2005 14:52:04 +0200, sawik <sawik@go2.pl> wrote:

>aditya wrote: >> 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
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 ?
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:

> 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 ?

aditya wrote:
> @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?
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.
> 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?
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.
> 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
aditya wrote:
<memory corruption>

> Any further pointers or solutions are welcome. >
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!"
"aditya" <vitgroup@gmail.com> wrote in message 
news:1118936341.235217.326010@g44g2000cwa.googlegroups.com...
> 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.
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
On Fri, 17 Jun 2005 02:05:01 +0100, "Steve at fivetrees" <steve@NOSPAMTAfivetrees.com> wrote:

>"aditya" <vitgroup@gmail.com> wrote in message >news:1118936341.235217.326010@g44g2000cwa.googlegroups.com... >> 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. > >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.
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.