Forum Discussion
Nios crashes when reading from the DDR2
Hi,
I'm trying to setup the DDR2 as a frame buffer for streaming to a display. Currently, I am able to write and read pixels to and from the off-chip DDR2 and communicate with custom hardware. The problem arises when I run my driver for more than a few seconds. For example, in SignalTap I see valid pixels going in and out for a few seconds, but then it just stops finding the trigger, ie my driver crashes. I've checked in debug mode, and after stepping through the code for a while, it crashes all of a sudden on a read from the DDR2 -- even after being successful at reading a few times before. The error message is just "Processor failed to go into debug mode when requested". I've also noticed that if I increase the amount of DDR2 memory that I'm using, it will crash instantly. I've attached my driver below. I've tried several ways of doing it, but they all yielded the same result. Any help would be really appreciated. I'm using Nios 8.0 and the DDR2 SDRAM High Performance Controller 8.0. Let me know if you have any questions. Thanks! Andrew20 Replies
- Altera_Forum
Honored Contributor
Erratic, inexplicable behavior is quite often due to not meeting timing requirements. Is your design meeting timing?
Jake - Altera_Forum
Honored Contributor
Did you run the HPDDR controller pin constraints script (.tcl) and add the time constraints script (.sdc) to the Quartus II project? You need to run/add both to fit/meet offchip timing.
- Altera_Forum
Honored Contributor
Thank you both for your replies. Yes, my design meets timing and I've run the .tcl files and included the .sdc file.
I spent the day making sure I had done everything right throughout my project. I am still having the same problem though! Now, I've discovered that my Tis, Tih, Tds, Tdh values are not correct. But I don't know how to find the values in order to derate them. I think it would be a whole lot easier if the DE3 board documentation would specify these in their brief tutorial. I was originally using the values given for the Stratix III development board, but they are obviously different from board to board. Also, the DE3 documentation doesn't give any board trace delay values, so there is no way of me taking them into account in my timing analysis (unless there is another way of finding them). - Altera_Forum
Honored Contributor
I figured out where to get the values for slew rate derating with DDR2. If anyone else who is relatively new at this has the same problem, this might help.
This pdf has some good info on what the values actually mean. http://www.ansoft.com/si/pdf/memory_made_easy.pdf And I used the equations given in this user guide: http://www.altera.com/literature/hb/external-memory/emi_tut_ddr.pdf The base values, Tis(base) etc., I found from the memory vendor data sheet. For the time being, I am going to assume the same slew rate values as the Stratix III dev board. (I'm using the DE3 board). This will hopefully give me the right timing in order to fix the erratic errors occurring when reading from the DDR2. Andrew - Altera_Forum
Honored Contributor
Hey again,
Ok, so I have all the right timing now. But the Nios is still freezing up for some reason! If I write 128 bytes to the DDR2 and read them back, it works fine. But when I try to write 256 bytes or larger and read them back the Nios stops working altogether. When this happens, in SignalTap I can see that none of the pio registers are being written to anymore, so that means the Nios just halted. If I assume that timing to the DDR2 is correct, and that even if it wasn't it shouldn't be crashing the Nios, but just giving all F's -- what would cause the Nios to freeze up? Andrew - Altera_Forum
Honored Contributor
Can you post a picture of your SoPC system? Do you by chance have a clock-crossing bridge between your NIOS and the memory controller?
Jake - Altera_Forum
Honored Contributor
- Altera_Forum
Honored Contributor
Does the NIOS "hang"? And does it occur when writing or when reading?
Jake - Altera_Forum
Honored Contributor
Yes, the NIOS "hangs", meaning, if in debug mode and pressing the run button, I would see nothing triggering in SignalTap, and when pressing the pause button, it exits saying "processor failed to go into debug mode when requested." To be more precise, in SignalTap I see correct reads for a few pixels being written and then read, and then it hangs at some point.
When stepping through the code it always hangs when attempting a read from the DDR2, but not always on the first read. - Altera_Forum
Honored Contributor
Try something just for fun. Disable the clock-crossing bridge and replace it instead with a pipeline bridge. Make the pipeline bridge use the DDR2 system clock for it's clock domain. SoPC builder will create a clock crossing adapter when you generate the system but we just want to see if it's working.
Also, are you sure you have your reset to the DDR2 controller properly connected? Jake