Primitive debuggable UART interface to a Nios within a multi

Ang Zhi Ping · Jul 28, 2014

I am working on an IP core with a Nios controller. This IP will
eventually be integrated into a multi-Nios system. I also foresee that
this IP will not be JTAG debuggable because the integrator will be using
the JTAG facility on a higher level Nios controller.

In this case I have planned to include a UART interface, which allows
the integrator to do on-the-fly primitive debugging with the IP using a
spare serial port, while at the same time using the JTAG debugger on
other Nios controllers.

Currently this is what has been implemented. The Nios controller waits
for 3 seconds, where upon receipt of a character 'd' within this period
it goes into diagnostic mode, otherwise it enters normal operation
without stdin and stdout. In diagnostic mode internal values are spewed
onto the console. I am planning to allow entry of an integer which
defines a bit pattern, where different bits selectively enables/disables
printing diagnostic messages. The console also allows input of an bit
pattern which selectively modifies internal parameters.

These modifications comes at the expense of adding several alt_printf
and alt_getchar which quickly clutters the Nios firmware code. Are there
any elegant method where an existing Nios firmware can be hooked onto a
debuggable framework via the UART? Even better, are there any memory
efficient way of performing gdb over a UART without hosting a full blown
OS on the Nios?

---
This email is free from viruses and malware because avast! Antivirus protection is active.
http://www.avast.com

mnentwig · Jul 28, 2014

Hi,

what I'm doing in a similar application is to put a UART to the bus a
addressable register, together with a four-byte FIFO. On bus read, the FIF
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:
https://drive.google.com/file/d/0B1gLUU8hXL7vc0xZa1ZmMUJIbjg/edit?usp=sharing
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 th
result is routed via "MIDI_read" to the processor's data bus in the nex
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 <= MIDI_RX;
sk61_serialRx #(.nBitCycles(3072)) iMidiUart(.clk(clk)
.in_rx(MIDI_RX_r), .out_byte(MIDI_byte), .out_strobe(MIDI_strobe));

// ************************************************************
// MIDI FIFO
// ************************************************************
wire MIDI_rxStrobe;
wire [7:0] MIDI_rxData;
serialFifo2bus iMidiFifo
(.i_clk(clk),
.i_push(MIDI_strobe), .i_byte(MIDI_byte),
.i_pop(busSel_MIDI), .o_busword(MIDI_read));

---------------------------------------
Posted through http://www.FPGARelated.com

Ang Zhi Ping · Jul 28, 2014

On 28/7/2014 1:04 PM, Tim Wescott wrote:

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

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.

Tim Wescott · Jul 28, 2014

On Mon, 28 Jul 2014 07:20:31 +0800, Ang Zhi Ping wrote:

I am working on an IP core with a Nios controller. This IP will
eventually be integrated into a multi-Nios system. I also foresee that
this IP will not be JTAG debuggable because the integrator will be using
the JTAG facility on a higher level Nios controller.

In this case I have planned to include a UART interface, which allows
the integrator to do on-the-fly primitive debugging with the IP using a
spare serial port, while at the same time using the JTAG debugger on
other Nios controllers.

Currently this is what has been implemented. The Nios controller waits
for 3 seconds, where upon receipt of a character 'd' within this period
it goes into diagnostic mode, otherwise it enters normal operation
without stdin and stdout. In diagnostic mode internal values are spewed
onto the console. I am planning to allow entry of an integer which
defines a bit pattern, where different bits selectively enables/disables
printing diagnostic messages. The console also allows input of an bit
pattern which selectively modifies internal parameters.

These modifications comes at the expense of adding several alt_printf
and alt_getchar which quickly clutters the Nios firmware code. Are there
any elegant method where an existing Nios firmware can be hooked onto a
debuggable framework via the UART? Even better, are there any memory
efficient way of performing gdb over a UART without hosting a full blown
OS on the Nios?

---
This email is free from viruses and malware because avast! Antivirus
protection is active.
http://www.avast.com

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

Jul 28, 2014

On Monday, July 28, 2014 2:20:31 AM UTC+3, Ang Zhi Ping wrote:

I am working on an IP core with a Nios controller. This IP will

eventually be integrated into a multi-Nios system. I also foresee that
this IP will not be JTAG debuggable because the integrator will be using
the JTAG facility on a higher level Nios controller.

In this case I have planned to include a UART interface, which allows
the integrator to do on-the-fly primitive debugging with the IP using a
spare serial port, while at the same time using the JTAG debugger on
other Nios controllers.

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...

Ang Zhi Ping · Jul 28, 2014

On 28/7/2014 6:22 PM, already5chosen@yahoo.com wrote:

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.

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

Jul 28, 2014

On Monday, July 28, 2014 3:10:40 PM UTC+3, Ang Zhi Ping wrote:

On 28/7/2014 6:22 PM, already5chosen@yahoo.com wrote:

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.

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

Did you assign different instance IDs?

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

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

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

Jul 28, 2014

On Monday, July 28, 2014 3:10:40 PM UTC+3, Ang Zhi Ping wrote:

On 28/7/2014 6:22 PM, already5chosen@yahoo.com wrote:

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.

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

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

mnentwig · Jul 29, 2014

>> the topic was "light" debugging with printouts.

BTW my on-board VGA controller may seem a little over-the-top . The mai
selling point is, it doesn't slow down the code, it's an infinite-baudrat
UART. It's surprisingly compact if I can spare one clock and a block RA
(on Xilinx Spartan 6, haven't tried this yet on Altera).
Electrically it's uncritical, patch cables to a cheap RGB resistor DA
breakout board / "wing" work just fine at 640x480 / 25 MHz.

---------------------------------------
Posted through http://www.FPGARelated.com

Ang Zhi Ping · Jul 29, 2014

On 29/7/2014 4:14 AM, already5chosen@yahoo.com wrote:

Did you assign different instance IDs?

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

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

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.

> I did try software download (which aso uses debugger interface) to different Nios2 processors over the same JTAG interface. It certainly works. I never tested if it works simultaneously, because I never wanted to download simultaneously.

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

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

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

Jul 29, 2014

On Tuesday, July 29, 2014 6:20:10 AM UTC+3, Ang Zhi Ping wrote:

On 29/7/2014 4:14 AM, already5chosen@yahoo.com wrote:

Did you assign different instance IDs?

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

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

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.

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 interaction of resets.

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

The JTAG certainly work for multi-Nios system, but it cannot handle

stdout from multiple Nios.

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

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

Jul 29, 2014

On Tuesday, July 29, 2014 5:20:53 AM UTC+3, mnentwig wrote:

the topic was "light" debugging with printouts.

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.

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

Jul 30, 2014

On Wednesday, July 30, 2014 1:47:16 AM UTC+3, rickman wrote:

On 7/29/2014 10:34 AM, already5chosen@yahoo.com wrote:

You constantly use the phrase "JTAG UART" - single, instead of "JTAG UARTs" - multiple. May be, that's where your problem lies?

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.

Theo Markettos · Jul 30, 2014

rickman <gnuarm@gmail.com> wrote:

On 7/29/2014 10:34 AM, already5chosen@yahoo.com wrote:

You constantly use the phrase "JTAG UART" - single, instead of "JTAG
UARTs" - multiple. May be, that's where your problem lies?

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

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

glen herrmannsfeldt · Jul 30, 2014

rickman <gnuarm@gmail.com> wrote:

On 7/29/2014 10:34 AM, already5chosen@yahoo.com wrote:

You constantly use the phrase "JTAG UART" - single, instead
of "JTAG UARTs" - multiple. May be, that's where your problem lies?

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

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

rickman · Jul 30, 2014

On 7/29/2014 10:34 AM, already5chosen@yahoo.com wrote:

You constantly use the phrase "JTAG UART" - single, instead of "JTAG UARTs" - multiple. May be, that's where your problem lies?

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

--

Rick

rickman · Jul 30, 2014

On 7/29/2014 7:05 PM, already5chosen@yahoo.com wrote:

On Wednesday, July 30, 2014 1:47:16 AM UTC+3, rickman wrote:
On 7/29/2014 10:34 AM, already5chosen@yahoo.com wrote:

You constantly use the phrase "JTAG UART" - single, instead of "JTAG UARTs" - multiple. May be, that's where your problem lies?

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

Ang Zhi Ping · Jul 30, 2014

On 29/7/2014 10:34 PM, already5chosen@yahoo.com wrote:

On Tuesday, July 29, 2014 6:20:10 AM UTC+3, Ang Zhi Ping wrote:
On 29/7/2014 4:14 AM, already5chosen@yahoo.com wrote:

Did you assign different instance IDs?

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

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

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.

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 interaction of resets.

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

Jul 30, 2014

On Wednesday, July 30, 2014 3:52:10 AM UTC+3, Ang Zhi Ping wrote:

On 29/7/2014 10:34 PM, already5chosen@yahoo.com wrote:

On Tuesday, July 29, 2014 6:20:10 AM UTC+3, Ang Zhi Ping wrote:

On 29/7/2014 4:14 AM, already5chosen@yahoo.com wrote:

Did you assign different instance IDs?

Yes different instance IDs are assigned. The JTAG UART under Eclipse IDE

is able to tell the different NIOS.

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

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.

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 interaction of resets.

Yes we only have a single JTAG port for our embedded target,

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.

> but multiple serial ports to spare.

Adam Górski · Jul 30, 2014

W dniu 2014-07-28 14:10, Ang Zhi Ping pisze:

On 28/7/2014 6:22 PM, already5chosen@yahoo.com wrote:
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.

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

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

---
Ta wiadomoĹÄ e-mail jest wolna od wirusĂłw i zĹoĹliwego oprogramowania, poniewaĹź ochrona avast! Antivirus jest aktywna.
http://www.avast.com

Primitive debuggable UART interface to a Nios within a multi

Ang Zhi Ping

Guest

mnentwig

Guest

Ang Zhi Ping

Guest

Tim Wescott

Guest

Guest

Ang Zhi Ping

Guest

Guest

Guest

mnentwig

Guest

Ang Zhi Ping

Guest

Guest

Guest

Guest

Theo Markettos

Guest

glen herrmannsfeldt

Guest

rickman

Guest

rickman

Guest

Ang Zhi Ping

Guest

Guest

Adam Górski

Guest

Welcome to EDABoard.com

Sponsor

Online statistics

Forum statistics

Primitive debuggable UART interface to a Nios within a multi

Ang Zhi Ping

Guest

mnentwig

Guest

Ang Zhi Ping

Guest

Tim Wescott

Guest

Guest

Ang Zhi Ping

Guest

Guest

Guest

mnentwig

Guest

Ang Zhi Ping

Guest

Guest

Guest

Guest

Theo Markettos

Guest

glen herrmannsfeldt

Guest

rickman

Guest

rickman

Guest

Ang Zhi Ping

Guest

Guest

Adam Górski

Guest

Log in

Welcome to EDABoard.com

Sponsor