booting from a tightly coupled memory

I would use 'objdump -d' to disassemble the elf file to see what code is where, then compare the binary data (of the instructions) with the .hex file (I think you can persuade objdump to disassemble the .hex file if you give it enough info).

It might also be worth proving you can get the code running with a smaller image (and maybe other stuff removed) to allow additional diagnostics. Making one of you cpus access via a small I-cache will let both have data access to the code space - which might help diagnosis.

Also, you need to ensure the instruction memory only contains code. The linker script is likely to put any readonly data into that segment, and the gcc4 build from altera will always put switch-statement jump tables into the code segment.

I have run systems with code in tightly coupled memory where the cpu doesn't have data access to the instruction memory (in my case it is visible externally). I was going to make a shared data area TCM between two nios, but in the end I used an uncached data master so that I could read the contents for diagnostics.