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
Primitive debuggable UART interface to a Nios within a multi-Nios system
Started by ●July 27, 2014
Reply by ●July 28, 20142014-07-28
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.comWhy 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
Reply by ●July 28, 20142014-07-28
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.
Reply by ●July 28, 20142014-07-28
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: 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 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 <= 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
Reply by ●July 28, 20142014-07-28
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...
Reply by ●July 28, 20142014-07-28
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.
Reply by ●July 28, 20142014-07-28
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: >=20 > > Multiple Nios2 cores, each with its own JTAG UART, co-exist just fine o=n the same JTAG interface. The same applies to multiple JTAG debug modules.>=20 > > The only thing that you, as designer of the module, should care about i=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.>=20 >=20 >=20 > 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 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.
Reply by ●July 28, 20142014-07-28
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.
Reply by ●July 28, 20142014-07-28
>> 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. --------------------------------------- Posted through http://www.FPGARelated.com
Reply by ●July 29, 20142014-07-29
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.
