booting from a tightly coupled memory

[Altera_Forum]

INTRO: 

 I'm trying to desing a system where two NiosII share the same instruction TCM. I need that for the design to fit the available M9K and achieve the required performance. It should work as both processors have exactly the same configuration and memory map and all..  I'm using a dual-port on-chip ram and each NiosII has it's tightly coupled instruction master connected to one of the memory ports. There's a problem with that: I have no port left so I can write to this memory. So, the only way out is to initialize this memory while configuring the device.  THE PROBLEM:  I do "make mem_init_generate" from the NiosII application directory. That gives me a <tcmname>.hex file I guess I should use to initialize the memory. That seems to work (I generate the sof, configure the device and I'm able to read the tcm using system console), although the software don't get to main(). Instruction address offset 0x50 is a jump (bne) to some wrong address. It seems _start code at this address, as shown by "nios2-elf-nm | sort": 01000020 T _start 01000058 t alt_after_alt_main  So, it seems the _start at the generated memory initialization .hex file is not pointing to the tcm, right? Any clue about that?  Thanks in advance!

[Altera_Forum]

Did you remember to point the Nios II reset vector at the TCM? It should be just a matter of making sure reset is set appropriately and having .text pointed at the TCM (or at least the section of code you plan on putting in the TCM). 

 Also I recommend using two TCMs, one per CPU while you are prototyping your software so that you can hook the 2nd memory port to the data master. That way you can make code changes and download them to the board. Then when you are finished with the software pull out one of the TCMs and hook up the 2nd CPU to the shared TCM.

[Altera_Forum]

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.