Issues retrieving services for Cyclone II in system console

Question

Hello there,
I am working with an old Cyclone II based project. I having hard time to access my custom module via JTAG. As I cannot use the In-System Memory Content Editor I tried to instantiate:
- a JTAG-to-Avalon-MM master bridge IP- a NIOS II processor- an In-System Sources &amp; Probes IP
Yet none of them gives me access to my custom module.I attach few pictures to depict my situation:
The QSYS system

The netlist viewTo inspect all possible discovered service paths I run the command:
foreach service [get_service_types] {puts "type '$service': [get_service_paths $service]"}
Resulting in:
type 'bytestream': {/devices/EP2C(15|20)@1#USB-1/(link)/JTAG/(110:128 v1 #0)/jtaguart_0}
type 'dashboard': 
type 'design': /designs/internal_stats_d013.qpf
type 'design_instance': 
type 'device': /devices/EP2C(15|20)@1#USB-1
type 'gdbserver': 
type 'issp': 
type 'jtag_debug': 
type 'loopback': 
type 'marker': /devices/EP2C(15|20)@1#USB-1 {/devices/EP2C(15|20)@1#USB-1/(link)/JTAG/(110:128 v1 #0)} {/devices/EP2C(15|20)@1#USB-1/(link)/JTAG/(70:34 v3 #0)} {/devices/EP2C(15|20)@1#USB-1/(link)/JTAG/(70:34 v3 #0)/nios2_0}
type 'master': {/devices/EP2C(15|20)@1#USB-1/(link)/JTAG/(70:34 v3 #0)/nios2_0}
type 'monitor': /design_instances/monitor
type 'plugin': /plugins/com.altera.systemconsole.dashboard.internal.DashboardPluginProvider /plugins/com.altera.systemconsole.designs.internal.DesignsPluginProvider /plugins/com.altera.systemconsole.gdbserver.GdbServerPluginProvider /plugins/com.altera.systemconsole.gui.desktop.DesktopPlugin /plugins/com.altera.systemconsole.internal.plugin.jtag.JtagPluginProvider /plugins/com.altera.systemconsole.internal.plugin.jtag.aji.AJIConnectionProvider /plugins/com.altera.systemconsole.internal.plugin.memory.MemoryPluginProvider /plugins/com.altera.systemconsole.issp.internal.ISSPPluginProvider /plugins/com.altera.systemconsole.monitor.internal.MonitorPluginProvider /plugins/com.altera.systemconsole.nios2.dpx.DPXPlugin /plugins/com.altera.systemconsole.plugin.pli.PliDeviceProvider /plugins/com.altera.systemconsole.scripting.UserScriptSupport /plugins/com.altera.systemconsole.scripting.ui.ConsolePlugin /plugins/com.altera.systemconsole.tcpchannel.TCPChannelPluginProvider /plugins/com.altera.systemconsole.usb.USBConnectionProvider
type 'processor': {/devices/EP2C(15|20)@1#USB-1/(link)/JTAG/(70:34 v3 #0)/nios2_0}
type 'sld': {/devices/EP2C(15|20)@1#USB-1/(link)/JTAG/(110:128 v1 #0)} {/devices/EP2C(15|20)@1#USB-1/(link)/JTAG/(70:34 v3 #0)}
 As can be seen the issp service returns no path. On the other hand the access via NIOS II gives me unexpected memory readout (I expected a bunch of zeros). Moreover my custom module can be only read, yet I am able to write new values and read them back. I am accessing the 0x3000 to 0x307F memory section where (according to QSYS) my custom module is mapped to.

sstrell · Answer

The JTAG-to-Avalon bridge has to be in your Platform Designer system, added from the IP Catalog there, and connected to your custom component.  It looks like you've added it outside the system and it's not connected to anything.  ISSP should be in the system (can also be added from Platform Designer IP Catalog) and connected to the custom component as well.  Also, for some reason, you have the sources and probes connected to each other which doesn't make much sense unless you're just testing to see that the probes display whatever you set the sources to.

sfava · Answer

I am sorry for the confusion, but the ISSP is one left over of my many attempts to make this tool work (this is why it is connected in a loop), yet I understand that it should have been instantiated in the QSys tool, thanks for the correction.

The "jtag_avalon_bridge:jtag_avalon_bridge_inst" is a QSys system instantiation (I am using Quartus 11.1). The "internal_stats" module inside the QSys system is the custom module I would like to debug.
As I mentioned the access through the NIOS is still not working. Any idea about what might it be wrong there? The address spaces are mutually exclusive and the "data_master" from the CPU is connected to the "tb_avs" of the "internal_stats". Despite this is a read-only interface I can also write to its memory space and the values I see are not as expected (I would expect almost all memory sections being zeroed).

For your reference have a look at the screenshot below: