- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic to the Top
- Bookmark
- Subscribe
- Printer Friendly Page
Memory corruption in custom board
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Highlight
- Email to a Friend
- Report Inappropriate Content
10-16-2008 05:51 AM
Hello everybody.
Sorry to bother you.
I have built a custom board based on Spartan3E 1200, 16 MB Numonyx flash and 64 MB Micron ram (2 x MT48LC32M8A2).
I installed petalinux on it (http://developer.petalogix.com/). I know this is not the right place to ask for help, but I already asked on the petalinux mailing list about thisproblem and I'm starting to think it's an EDK issue.
If I start multiple applications in Linux - snmp daemon and tftp transfer for example - the kernel suddenly crashes complaining about the memory having been corrupted.
Both applications run fine if started alone.
What makes me think about a design issue is that I can run the same executable (linux kernel + applications) on both my custom board and a Xilinx Spartan3E 1600E evaluation board.
On the evaluation board no crashes can be seen. Their main difference is in the memory used: DDR in the evaluation board and SDRAM in my custom board.
I already tried putting up a small debug application, executed at microblaze boot, to write the whole memory one byte at a time in an infinite loop. No error is found and the memory is written correctly (checked via jtag debug).
EDK is version 9.2i and Microblaze 6.00.b.
I already tried with different settings:
- no cache on microblaze
- sdram controller with and without multi-channel
- ethernet
- ethernet lite
- opb bus @ 50 MHz
I always experience the same behaviour.
Note: I'm not using the sdram feedback at the momet
I know this problem is hard do describe and to understand, even more if we consider the fact that it may be related just to the Linux kernel, but I would like to know if anybody else has encountered a similar problem or can suggest me some more tests to try.
I would be very glad.
Many thanks for your time and effort.
Giulio Mazzoleni
Solved! Go to Solution.
Re: Memory corruption in custom board
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Highlight
- Email to a Friend
- Report Inappropriate Content
10-22-2008 01:11 AM
It was a design issue in an incorrect setting in SDRAM parameters
(column width).
It was causing RAM being overwritten by different adresses.
It was not showing up in my simple RAM test because I was testing RAM
alternating a write and a read. It would have been more helpful writing
the whole ram with a known sequence of data and reading it back.
Many thanks for your help.
Giulio Mazzoleni
Re: Memory corruption in custom board
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Highlight
- Email to a Friend
- Report Inappropriate Content
08-31-2010 05:16 AM
How start with SDRAM on board Spartan 3AN - simple aplication read write data to SDRAM on RS232?
Re: Memory corruption in custom board
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Highlight
- Email to a Friend
- Report Inappropriate Content
08-31-2010 05:48 AM
Hi xeon.
I am no expert, but maybe I can give you a few hints. Hope somebody else more experienced could answer you as well (and correct me if I am wrong).
It seems that every EDK project comes with a few tests (for memory and peripherals). You can start to enable them when compiling the bitstream, even if they are run in a non interactive way.
I used to work with petalinux and uboot bootloader comes with some memory tests, too.
Anyway, to read/write from memory it simply a matter of using the right memory address.
*(volatile unsigned int *) MEM_ADDR
*(volatile unsigned short *) MEM_ADDR
*(volatile unsigned char *) MEM_ADDR
You can find the correct address by watching the address map in the XPS project.
Then you can modify the code of the little program that get compiled in the bitstream.
For example:
*(volatile unsigned int *) 0x8000F000 = 24;
unsigned int x = *(volatile unsigned int *) 0x8000F000;
or using the proper accessory functions (in_8, in_16, in_32, out_8, out_16, out_32 depending of your software environment).
Hope to have been of some help.
Please provide a few more details if you want a more precise answer.
Giulio











