- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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?Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Added note: in ModelSim, I do get printf output from both SOPC systems as it should, so this is definately a Quartus issue.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
You should be able to switch between the two using the -i command line argument like this:
nios2-terminal -i 0 nios2-terminal -i 1 (assuming they are instance 0 and 1, look at the .jdi file to make sure) Typically when I'm looking at multiple UARTs I do this from the command line so that I can have multiple nios2-terminals open at once.- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi,
Maybe I was not clear enough, I can connect to both JTAG UARTs (indeed by passing the instance numbers as mentioned above by BadOmen), but the problem is that the JTAG UART of SOPC#2 does not output anything.- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
At the command line type this "jtagconfig -n". It'll report your JTAG cables, devices, and all the JTAG nodes in your FPGA(s). I'll be able to spot the JTAG UARTs in the output.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
hi guys .....
i have a system with 2 cpu ...one running nios and another running linux..... i had some problens with 2 jtags.........and a solution ....remove 1 jtag and put a serial port :) voila! dont forget --instance=(your instance) try it Franz Wagner- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
--- Quote Start --- hi guys ..... i have a system with 2 cpu ...one running nios and another running linux..... i had some problens with 2 jtags.........and a solution ....remove 1 jtag and put a serial port :) voila! dont forget --instance=(your instance) try it Franz Wagner --- Quote End --- 2 jtags? Do you mean 2 JTAG devices (such as a JTAG debug core and a JTAG UART), or 2 JTAG UARTs? I assume using a serial port would require a hardware change?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
--- Quote Start --- 2 jtags? Do you mean 2 JTAG devices (such as a JTAG debug core and a JTAG UART), or 2 JTAG UARTs? I assume using a serial port would require a hardware change? --- Quote End --- In a project with two cpus is not a good idea use jtag for debug (only for signal tap). I had many problems with it. Today I use two serial ports for debug of cpus and just use the jtag to download programs. to use a serial port you only need put serial uart on sopc builder . sopc create to pins ..... tx and rx .... . you conect it on two external pins and put it on serial port of you machine (pc)....... use db9 conector ........ pins 2 and 3..........(and conect the ground ....) cheers Franz Wagner
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thanks for the tip - i'll keep it in mind for another piece of hardware. For this project however, it is not possible to modify the hardware.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
--- 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?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
--- 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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
--- 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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page