--- Quote Start ---
originally posted by badomen@Mar 27 2007, 07:00 PM
here are some things to check:
1) do you have a data cache? if so are you bypassing it when you talk to peripherals/share data with other processors in your system
2) does nios ii talk to your fifos? 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).
3) are you low on memory? could be a heap + stack collision (if adding significant amounts of code fixes the problem then this is unlikely). these are hard to debug but you can try minimizing the code or filling a few locations with known data and seeing if it's getting clobbered by connecting to the system with the debugger.
4) are you recompiling hardware? if so are you absolutely sure you have all your pins assigned? if not then quartus ii will move pins around to improve timing but this could cause functional problems on your board.
5) if you haven't already done so have your enabled -o0 software optimization?
6) if you use dcfifo to go across clock domains have you setup the synchronized clock setting properly? (if your answer is "huh?" go with unsynchronized clocks so that an extra register is inserted)
7) try stepping through code. wherever in the code the cpu goes off into the weeds will help isolate the problem in most cases.
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.
<div align='right'><{post_snapback}> (index.php?act=findpost&pid=22573)
--- quote end ---
--- Quote End ---
Definitely some good suggestions. I don't have clock-domain crossing, so that shouldn't be an issue for me. Also, I have plenty of SRAM available, so no chance of heap/stack collision. I am using alt_uncached_mallocs(), and I'm not sure how proven they are. I think the best suggestion for my case is turning off optimization; I haven't tried this yet, but I recall from past experiences with other processors that optimization always introduces headaches!
thanks again.