Forum Discussion
Honored Contributoruncontrolled SDRAM content change
Hi,
I use a code which checks external SDRAM () by writing 0xAAAA and 0x5555 patterns. But the code always return an error code! When I check step by step SDRAM content with NIOSII IDE I can see (with the memory monitor) that data cell changes well at desired address but a lot of other cells change at same time around the desired address. The other cells have arbitrary value but all change with the same value. I don't understand why because I just do a simple loop with an IOWR and an offset increment of 1 (for 32bit cell increment) - All the code resides inside the onchip memory (.text + .data + heap + stack) so nothing should access to SDRAM - reset and exception vectors point to onchip memory - PLL is well configured for SDRAM - No compilation error or warning I'm sure the hardware is OK because when running with the "normal" firmware and .sof (in this case code resides inside SDRAM) and everything is OK. I use an EP3C40F484I7 cyclone III FPGA with a Micron MT48LC4M32B2 SDRAM, Quartus and NIOS II 9.0SP215 Replies
Altera_Forumthe random values could come from data cache flushes. As you are writing with IOWR, if for some reason those addresses were cached, when flushing the cache the old values are written back to memory.
Did you try using pointers instead of IOWR? That way you will access the memory through the data cache.- Altera_Forum
If this is actually a cache problem, you should overcome it using uncached addresses : sdram_address + 0x80000000
- Altera_Forum
I don't think it is a cache issue because I only access SDRAM with the IOWR and IORD commands. The code is very simple and never access to SDRAM by another way.
And even no access to SDRAM, a lot of memory cells content are changed at every step (using F5 step with debug) and that have no sense for me! I will try using pointers - Altera_Forum
I tried with read and write pointer access but it changes nothing:
During the sequential write loop, each cell is correctly written, but some steps after the same cell is written again (why???) with a random dummy val! here the original simple code: for (offset = 0; offset < nWords; offset++) { IOWR(baseAddress, offset, pattern1); } - Altera_Forum
Are you sure the parameters of the sdram controller match your MT48LC4M32 device? I mean CAS latency, refresh period, tRCD, tRAS and so on.
Is your Quartus project fully time constrained and does it meet timing? What's the Nios/sdram clock frequency? - Altera_Forum
Don't just add 0x8000_0000 to a pointer to bypass the cache, use the cache remapping macros since there are flushes involved as well. They are documented in the software developer's handbook. You might not see a behavior change since the flush is only necessary for some corner cases but you should get into a habit of using the APIs and not flipping bit 31 of your pointer locations.
- Altera_Forum
Yes I'm sure SDRAM settings are correct and constraint are also given for Quartus and no error/warning is present after compilation.
External frequency is 50MHz and internal (PLL outputs) are 80MHz But now I remember I use the NiosII/e CPU. So it can't be a cache issue because this version of CPU doesn't manage cache at all! I continue to investigate. If somebody has any other idea... you are welcome :confused: - Altera_Forum
I don't know how the memory monitor works, but it could go through the data cache, and therefore use it and trigger cache flushes/loads. Maybe someone knows how it is done.
Anyway it is always possible to define the cache size as 0 in the Nios parameters to disable the cache and see if the problems are still there. The only two other explanations I can find are indeed a problem in the SDRAM access parameters (especially the refresh rate, but in my experience you need several seconds to loose content when you messed up the DRAM refresh) or that something else, like a DMA, or an interrupt routine from the software, is overwriting your memory buffer. It could be a good idea to put some signaltap probes around the SDRAM controller to see if anything is happening. - Altera_Forum
Have you tried the memtest or the mini_memtest software examples that come on the ACDS? Those are coded to look for specific problems like stuck/shorted/open data or address bits. Being able to run code out of a memory doesn't necessarily mean it's working, there are all kinds of corner cases that can go unnoticed so I would test that memory with code *and* a DMA to make sure is it behaving properly.
- Altera_Forum
With signal tap I can see that SDRAM controller is running. I plugged scope probes and I can see that data, address and control signals voltages change at every SDRAM access.
My code is already based on memtest from Altera. I did some change to let test run until end of SDRAM even a step with error. Here is one test:
The errCounter tell me that all steps get an error! I can't believe the entire SDRAM is down!for (pattern1 = 1, offset = 0; offset < nWords; pattern1++, offset++) { IOWR(baseAddress, offset, pattern1); } for (pattern1 = 1, offset = 0; offset < nWords; pattern1++, offset++) { if (IORD(baseAddress, offset) != pattern1) { retCode = (baseAddress + offset); errCounter++; } }
