Primitive debuggable UART interface to a Nios within a multi-Nios system

Why not MUX the JTAG to the various processors, get this (presumably deeply buried one) debugged, and then move on?

--
Tim Wescott 
Control system and signal processing consulting 
www.wescottdesign.com

This module is more or less finalised and debugged. There are internal values within the hardware which are of use to the integrator who is debugging the top level controller.

Hi,

what I'm doing in a similar application is to put a UART to the bus as addressable register, together with a four-byte FIFO. On bus read, the FIFO is popped and empty/overflow conditions are reported in bits 30 and 31, together with the read result in bytes 7:0.

Example code is here:

It is for MIDI serial, for 31250 baud (use 9600 or 115200, for example).

It is functional but there may be bugs.

This is the interesting part in zpu_top.c: The address decoder asserts "busSel_MIDI" for a read operation, and the result is routed via "MIDI_read" to the processor's data bus in the next cycle.

The C code uses regular polling: while (1){ u32 c = *MIDI; // (volatile u32)* to the bus address if (c & 0x80000000){ printf("buffer overflow!n"); } else if (c & 0x40000000){ MIDI_parse(c & 0xFF); } }

My solution to deal with debug "printf" is a VGA adapter on the FPGA :-)

// ************************************************************ // MIDI UART // ************************************************************ // 96 000 000 Hz (clock) / 31250 Hz (MIDI baudrate) = 3072 = nBitCycles wire [7:0] MIDI_byte; wire MIDI_strobe; reg MIDI_RX_r = 1; always @(posedge clk) MIDI_RX_r

Multiple Nios2 cores, each with its own JTAG UART, co-exist just fine on the same JTAG interface. The same applies to multiple JTAG debug modules. The only thing that you, as designer of the module, should care about is avoiding the conflict of Nios2 CPU instance IDs. Ideally, allocation of instance IDs should be governed by person, that is responsible for top-level integration.

So, most likely, all your per-caution with physical UART is unnecessary. Of course, JTAG-independent printouts can be useful for other reasons...

I can't seem to debug two Nios processors simultaneously.

n the same JTAG interface. The same applies to multiple JTAG debug modules.

s avoiding the conflict of Nios2 CPU instance IDs. Ideally, allocation of i nstance IDs should be governed by person, that is responsible for top-level integration.

Did you assign different instance IDs?

I never tried to use debuggers on two Nios2 processors myself (I hate debug gers in general, so I didn't use debugger on *one* Nios2 processor for some thing like 7 years), but Altera documentation claims that it should work.

I did try software download (which aso uses debugger interface) to differen t Nios2 processors over the same JTAG interface. It certainly works. I neve r tested if it works simultaneously, because I never wanted to download sim ultaneously.

But all that is slightly off topic. The topic was "light" debugging with pr intouts. That's the method that I do like and do do regularly. Printouts ov er JTAG UARTs from different processor most definitely work simultaneously, there are no problems at all. Just specify correct instance ID in nios2-te rminal command line and everything will work for you in the best possible m anner.

P.S. alteraforum is a much better place for asking that sort of questions.

BTW my on-board VGA controller may seem a little over-the-top . The main selling point is, it doesn't slow down the code, it's an infinite-baudrate UART. It's surprisingly compact if I can spare one clock and a block RAM (on Xilinx Spartan 6, haven't tried this yet on Altera).

Electrically it's uncritical, patch cables to a cheap RGB resistor DAC breakout board / "wing" work just fine at 640x480 / 25 MHz.

--------------------------------------- Posted through

Yes different instance IDs are assigned. The JTAG UART under Eclipse IDE is able to tell the different NIOS.

If the JTAG UART is used for stdout, the JTAG only routes the debugging Nios to console. Any other Nios processors that are not being debugged will not be able to route their stdout outputs to console. Hence this question about routing messages via serial port.

The JTAG certainly work for multi-Nios system, but it cannot handle stdout from multiple Nios.

Haha ok let's keep this thread on topic then.

ebuggers in general, so I didn't use debugger on *one* Nios2 processor for something like 7 years), but Altera documentation claims that it should wor k.

You constantly use the phrase "JTAG UART" - single, instead of "JTAG UARTs" - multiple. May be, that's where your problem lies? You should use separate JTAG UARTs for separate Nios2 cores. Personally, I prefer not only separate JTAG UARTs, but completely separate SOPC (now known as QSYS) "systems". That way I better understand interactio n of resets.

erent Nios2 processors over the same JTAG interface. It certainly works. I never tested if it works simultaneously, because I never wanted to download simultaneously.

h printouts. That's the method that I do like and do do regularly. Printout s over JTAG UARTs from different processor most definitely work simultaneou sly, there are no problems at all. Just specify correct instance ID in nios

2-terminal command line and everything will work for you in the best possib le manner.

"Infinite-baudrate" is good, but difficulty of logging printouts into file is bad. For me, the later easily outweighs the former.

I know what a UART is, I know what JTAG means, but what is a JTAG UART?

--

Rick

From Quartus II Handbook: "The JTAG UART is an Avalon-MM slave device that can be used in conjunction with the System Console to send and receive bytestreams."

Now, if you are going to ask "What is "an Avalon-MM" and what is "the System Console" ?" then I am not going to answer.

No, lol. So this is an Altera specific term. Got it.

--

Rick

It's a terminal-like device that grabs hold of an internal interface to Altera's JTAG controller, with the result that you can attach a NIOS processor (or other endpoint) to it inside the FPGA, and then run a program called nios2-terminal on the host PC which receives the character input/output. In other words it's a character stream multiplexed over the host PC JTAG connection (which itself goes over TCP and then probably USB), instead of plugging in a serial cable to the FPGA.

The actual JTAG UART isn't really very UART-like though, it's somewhat lacking in the usual UART features.

I don't have anything major to contribute to the OP's question: I've run multiple JTAG UARTs out of one Qsys project, and that works fine. I haven't tried multiple NIOSes that I can recall, but these have multiple masters driving multiple UARTs (we have some hackery to make a JTAG UART accept Avalon streams by simulating writes to its config registers). I've also run

16 JTAG UARTs on the same JTAG chain, where each UART was on a different FPGA. That worked, if slightly flaky due to timing issues on the very long chain.

Theo

It does seem a strange term for it, but since JTAG is bit serial, and most systems use bytes or some larger word, there has to be a serial/parallel conversion somewhere along the way.

However, as I understand it, JTAG is synchronous, so that should be USRT instead of UART.

-- glen

Yes we only have a single JTAG port for our embedded target, but multiple serial ports to spare.

Of course, one Altera FPGA would at most have one JTAG port. That's not what I am talking about. I am talking about multiple instances of "jtag uart" component.

the same JTAG interface. The same applies to multiple JTAG debug modules.

avoiding the conflict of Nios2 CPU instance IDs. Ideally, allocation of in stance IDs should be governed by person, that is responsible for top-level integration.

Few years ago I had system with 8 Cyclon chips and each with nios II. All chips in single jtag chain. I was able to debug 2 or 3 of them at same time without any problem. There sould be not a problem to debug all 8 at once.

Adam

--

wego oprogramowania, poniewa? ochrona avast! Antivirus jest aktywna. 
http://www.avast.com