Honored Contributor
Honored ContributorBadOmen,
Thanks for your input. To answer your questions: >1) Do you have a data cache? no. I use the small footprint CPU which has no cache. In the past, I have tried changing to the other two cached processors and have had "working" code stop working. By "working" I mean with previously mentioned superfluous printfs and variable assignments. No amount of printf's or variable assignment shell-games could get them working to the level of the non-cache version. >2) Does Nios II talk to your FIFOs? I used the IP on the projects section of the forum. Nice interface. I have hardware/state machines and the NiosII talking to various FIFOs. Optimization is for size or speed. I also use the 'small C library" and "reduced device drivers" in the system library. I cannot get the code to fit w/o these setting. >If you communicate to it with a pointer do you declare the pointer volatile so that >the compiler doesn't optimize it away (if the compiler sees you reading from the >same location over and over it sometimes optimizes the other reads away and visa >versa for writes). No pointers. Instead of pointers, I use simple loops and integer indexes in loops to fill arrays. IIRC, reading the manuals said that "volatile" only affects cached processors, which I am not. >3) Are you low on memory? somewhat. 2400 bytes free for stack + heap. I'll try turning on the "run time stack checking" syslib option to check on collision. hmmm, just rebuilt the project and with stack checking enabled I now show 6660 bytes free. odd. I have tried optimizing for size and various speeds, each with their own unique "behavior". >4) Are you recompiling hardware? If so are you absolutely sure you have all your >pins assigned? yes and yes. compared .pin files of past builds and they are identical, i.e., no signal names moving on pins. >5) If you haven't already done so have your enabled -O0 software optimization? can't. >6) If you use DCFIFO to go across clock domains have you setup the synchronized >clock setting properly? Yes. That's why I'm using the FIFOs. I've double-checked and the LPMs are definitely set for non synchronized clocks. I've also try using LE's instead of RAM implementation to improve memory usage and speed, as well. >7) Try stepping through code. Wherever in the code the CPU goes off into the >weeds will help isolate the problem in most cases. When I revisit this software problem, I will set breakpoints and single step around the problematic code. Good idea! thanks. >I put these in the order of the most likely culprits. This is not a complete list but it's >a good starting place. Also I really doubt everyone is running into the same >problem because there are many things that can cause issues like you have >described. I agree that everyone is not seeing this problem. I've taken many Altera quartus and Nios classes and have never seen this problem in the canned examples, haven't talked to anyone having these issues, and have seen many people on this forum using Nios on realworld projects. However, it seems at least two of us are. Perhaps we're making the same mistakes. Fine. Just trying to find them. I REALLY appreciate your taking the time to think about the problem and making suggestions, all of which are good suggestions based on good engineering practices. On a final note, I believe I'm chasing two separate problems. One is affected by the printf's, etc. and is probably NiosII/memory related. The second problem is a state machine/FIFO communication problem and is probably timing related. On a whim, yesterday I recompiled the hardware turning off the Tsu, Tco, and Tpd constraints, i.e., only clocks set in timing analyzer. The reported delays are marginally slower than when constrained; however, now the misbehaving FIFO/state machine is fine. Need to revisit the memory problem. thanks. steve
