Forum Discussion

Altera_Forum's avatar
Altera_Forum
Icon for Honored Contributor rankHonored Contributor
14 years ago

Two SOPCs - SOPC#2 gives no jtag uart output

Hi guys,

I have a design that instantiates two different SOPCs, each containing its own NIOS II cpu and JTAG UART. I compiled a different C-app for each NIOS II.

Quartus compiles all OK, but when I run the design on hardware I get no JTAG UART output from SOPC#2 (I can connect to the cpu's JTAG debug module though).

When I recompile without SOPC#1, I do get output from SOPC#2.

Both generated system.h files (I'm using SOPC builder) list the correct (=different) UART names for the std_in/std_out definitions:

SOPC#1: system.h

# define ALT_STDIN "/dev/sopc1_jtag_uart"

SOPC#2: system.h

# define ALT_STDIN "/dev/sopc2_jtag_uart"

..so I'm lost as to what causes this problem. Any ideas?

18 Replies

Show More
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    14 years ago

    --- Quote Start ---

    Running more than one driver on the same JTAG UART will cause problems (for example the wrong CPU might clear an interrupt without sending data).

    If you're running the basic HAL (it looks like you are) then the easiest way to fix this is to connect each UART only to the CPU you want to use it with - that will prevent the other CPU from interfering with the JTAG UART hardware.

    --- Quote End ---

    I don't understand. I have two SOPCs (with their own JTAG UART, NIOS II + C app running on them) - I assumed them to be completely separate (they're generated separately and even instantiated about three entity levels apart from each other). Are you saying Quartus connects their buses together?
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    14 years ago

    I'm saying that you must not connect a JTAG UART to more than one CPU.

    It was not clear to me what you have built, but if the tools say they are not connected then they are not connected.
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    14 years ago

    --- Quote Start ---

    Yes, that does detect the JTAG UART (so it detects 2 JTAG debug instances and 2 JTAG UARTS in one FPGA). As said, I can connect to the JTAG UART, but it is not ouputting my printf messages.

    --- Quote End ---

    Did each JTAG UART end with a different instance ID? I forget what the value is but it should be something like 0C006Exx where xx should be unique between your two JTAG UARTs. If they overlap Quartus II should have raised an error during compilation so just check to make sure they don't indeed overlap.
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    14 years ago

    --- Quote Start ---

    Did each JTAG UART end with a different instance ID? I forget what the value is but it should be something like 0C006Exx where xx should be unique between your two JTAG UARTs. If they overlap Quartus II should have raised an error during compilation so just check to make sure they don't indeed overlap.

    --- Quote End ---

    Correct, I have two (different) IDs ending in 00 and two (different) IDs ending with 01. Funny thing is, I can download a new NIOS app onto the JTAG debug module of SOPC#2, I can also connect to the JTAG UART of SOPC#2 but it does not output my messages. SOPC#1 works fine.

    Also, I did not find any error messages in Quartus regarding the JTAG UART.
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    14 years ago

    Hmmmm running out of ideas here but another thing to check is that JTAG UART instance 00 is actually located in the SOPC Builder system containing JTAG debug module instance 00. It could be that the instance IDs for the JTAG UARTs are backwards compared to the JTAG debug modules. I typically look in the .jdi file to figure this out. The .jdi file lives in the Quartus II hardware project top level directory and contains the hierarchical names of all the JTAG nodes in your system and how they are setup.

  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    14 years ago

    Sorry to reopen this thread but did you manage to resolve this problem danv?

    I have an identical issue with 2 CPUs (but in one SOPC system) where the JTAG UARTs and CPU RAM blocks are completely unique to each CPU. In fact there is no commonality between the CPUs at this stage.

    I can download and verify the .elf to each CPU but only get a console output back from one of the CPUs.
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    14 years ago

    when you download the .elf you need to pass a parameter --instance

    like this

    nios2-download -g <.elf> --instance 1

    if you have 2 cpus you have instance 0 and instance 1

    good lucky

    Franz Wagner
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    14 years ago

    Since instance numbers can become jumbled during compilation the safest way to be sure is to inspect the .jdi file in the hardware project top level directory to figure out which core maps to which ID.

    For just downloading code I recommend using the name of the processor instead. If you have processors called "NiosA" and "NiosB" this is what you would do:

    nios2-download -r -g --cpu_name NiosA <elf for Nios A>

    nios2-download -r -g --cpu_name NiosB <elf for Nios B>

    nios2-terminal has a similar field called '--instance_name=NAME' so you just replace "NAME" with the name of your JTAG UART. Unfortunately the Nios II flash programmer doesn't have a similar feature at the command line (but in the SBT4E it probably can parse the instance out of the .jdi file for you).

    *edit* I think you have to supply the .jdi file at the command line for this to work. Type nios2-download --help for more details.