Nios® V/II Embedded Design Suite (EDS)
Support for Embedded Development Tools, Processors (SoCs and Nios® V/II processor), Embedded Development Suites (EDSs), Boot and Configuration, Operating Systems, C and C++
12626 Discussions

NIOS II hung .. how to break in with the debugger ?

Honored Contributor II

I have code running on the Stratix V + NIOS II with IMEM and PCIe IP. 


At some point the NIOS II hangs and I can't break in with the dubugger. 


Is this symptomatic of the NIOS II being stuck in a Load or Store operation ?  


I would like to use a non-buffered , non-interrupt driven stdio driver so that any printf is synchronized to where the program flow is ... 


So.. how to break in with the debugger and how to run non-buffered stdio. 


I am using the JTAG UART ... so it may be more difficult than a straight UART. 


I can use the LED's or the LCD on the Stratix V card as a "checkpoint" display but would rather leave the print statements or really be able to break in with the debugger. 


background : The same application works with Cyclone ... card ... ... The host sets a linked list of descriptors in in host, RC memory, informs the NIOS II via a mailbox IMEM where the head of the descriptor list is and the Host and the NIOS II work down the list and at a certain point the NIOS II hangs ....
0 Kudos
3 Replies
Honored Contributor II

I think you're seeking alt_log_printf() 


When things go off the deep end, the best tool unique to this environment that I have found is the SignalTap NIOS plugin, which doesn't get mentioned very frequently: 


And along the similar lines as writing to your LED's, you can also do things like have an assortment of PIO instances that you don't tie to anything except SignalTap or a Sources/Probes instance. For example, one PIO for "module" and one PIO for "line number" and riddle your code with TRACE() macros that write to those PIO's; hookup SignalTap and watch the writes to those PIO leading up to your crash. 


As far as why you are unable to break into your program, I've experienced the same but I don't think it is necessarily a load/store being stuck. 


Anyway - lots of things you can try, without feeling dependent on unbuffered UART's and LED's.
0 Kudos
Honored Contributor II

Thanks Ted....  


We have narrowed one fail on Stratix V PCIe at Gen3 X 4 to be some failure of a byte write, int writes operate fine but for some reason the byte write by NIOS II outbound to host memory turns into a 4 DWORD PCIe operation which I am not even sure is legal ... This is seen at both Gen3 X 4 and Gen1 X 4. 


I can either try to simulate it with a bus master replacing the NIOS II data master or as you indicate employ Signal Tap to see what transaction NIOS II sent to the PCIe TXS slave. 


Thanks Bob. 


Attached is an analyzer trace of what was supposed to be a byte write .. but I think the non contiguous byte enables is not legal.
0 Kudos
Honored Contributor II


This appears to describe the issue I see. The Avalon MM 128 bit fabric does not handle requests with byte enables of 0x1, 0x3 or 0x7 ... unfortunately the first case represents byte access and without that I can't use the PCIe IP from Altera. 


I have cut and paste the Solution ID etc as well as included the image below ... 


The problem is we are on Quartus 14.0.0 200 06 and note below indicate scheduled to be fixed in a future release ... I would have thought 14.0.0 would have it but maybe not . 


Shouldn't the Solution ID but updated when it is fixed ..  


I can't believe I am the only one stuck here ... do I nee dot go to Altera with a SR requesting a fix ? or is there an easier way. 


I have reviewed the RTL for byte enable interconnect on the Avalon MM fabric, but if the issue is in the bridge to the PCIe HIP then it needs to be fixed there. 



****************************************** start cut and paste ******************************************************************************** 


Solution ID: rd04172014_563 

Last Modified: May 02, 2014 

Product Category: Intellectual Property 

Product Area: Comm, Interface & Peripherals 

Product Sub-area: Core Implementation 

Version Found In: v13.1 update 4 

Version Fixed In: N/A 

Software: Quartus II Linux, Quartus II PC 


IP Product: PCI Express 1/2/4/8 Lanes (x8) 


Can the 128-bit Avalon-MM Txs slave interface of the Altera Hard IP for PCI Express handle read/write request with ByteEnable=0x01 ? 


Due to a problemin theQuartus® II software version 13.1 and earlier, the 128-bit Avalon-MM® Txs slave interface of the Hard IP for PCI Express® cannot generate a correct PCI Express TLPpacket when the ByteEnable = 0x01,0x03, or 0x7 at Avalon-MM interface. 


Avalon-MM bridges operate correctly with a burst count = 1 and the following byte enables (DW Byte Enable) 


16'hF000 16'h0F00 16'h00F0 16'h000F 16'hFF00 16'h0FF0 16'h00FF 16'hFFF0 16'h0FFF 16'hFFFF 


Workaround / Fix 

Use 64bit Avalon-MM Txs slave interface, or set ByteEnable to more than 0x07 (set 4 byte enable or more) with 128-bit Avalon-MM Txs slave interface within Quartus II software version 13.1 and earlier. 


This problem is scheduled to be fixed in a future release of the Quartus II software. 


****************************************end cut and paste ******************************************************************************************
0 Kudos