Normally I use HDL for everything, but I’m trying to move into soft processor and SoC design. I created a Quartus/Qsys project to run the Nios II Binary Count example code project on a DE0-Nano development board. I picked the Nios II economy core since it’s free.Everything worked from inside Eclipse (except for an occasional mystery error about timestamps not matching). I was able to run the Binary Count project and see the LEDs iterate endlessly through a counting pattern on the DE0-Nano hardware. At that point, I followed Altera’s instructions for generating a memory initialization file from Eclipse and adding it to the FPGA project. My goal was to have the board power up running the led_count code, so I added the memory init file, built the FPGA project to get an updated .sof, converted the .sof to a .jic, and programmed the .jic to flash on the DE0-Nano board. Now, when I power on the DE0-Nano I see the LEDs count. Success! Well, not quite. It only runs for about 1 minute before freezing. The LEDs count from 0-255, then 0-98. At that point they stop changing forever. It is 100% repeatable and always stops on the same value of 98. When running from Eclipse, the program never halts like this. I’m struggling to come up with a reason the program runs seemingly forever from Eclipse, but only lasts a minute when running standalone. Am I missing something obvious? For a reference, here is a screenshot of the Qsys design. https://www.alteraforum.com/forum/attachment.php?attachmentid=8401
The issue is likely the JTAG UART. I've never used it, but I'm pretty sure I recall that if there is no-one reading from it, its FIFOs fill up, and that likely causes the NIOS II writes to the (full) FIFO to block indefinitely.Search based on the JTAG UART, and you'll likely find recommendations for disabling it, or at least disabling the FIFO over-flow response, or simply remove it from your Qsys system, and try that. Cheers, Dave
Thank you for the reply. I tried removing the JTAG UART from the Qsys system (un-checking the use box) just now. Unfortunately, that broke the Eclipse project. It is no longer able to create a BSP due to errors related to the JTAG UART. I don't know how to hack up the Count Binary project to remove the need for the JTAG UART, so I will look into disabling the overflow response as you mentioned. It's too bad there's no check box for that in the peripheral in Qsys.
It's working now! I figured out how to remove the dependency on the JTAG UART in the Eclipse project, so that peripheral is officially out of the design like you suggested. The design has been free-running for several minutes without an issue.In case it is useful information to anyone else, I removed the dependency by right clicking the BSP project in Project Explorer, then selecting Nios II > BSP Editor. In the Main tab, under Settings > Common, I had to change stderr, stdin, and stdout to "none." Thanks a lot. Figuring out that it was an issue with the JTAG UART is the sort of thing that would've taken forever to find on my own.
--- Quote Start --- Thanks a lot. Figuring out that it was an issue with the JTAG UART is the sort of thing that would've taken forever to find on my own. --- Quote End --- Yeah, that is why I figured I'd comment. Thanks for posting your solution, so that it helps out the next poor soul to stumble over this problem :) Cheers, Dave
Note that you can put the JTAG UART back in the QSys project and just set stdout/stderr to none in the BSP settings. That way if you ever need to debug your project, you just need to change the bsp settings and don't need to recompile the QSys and Quartus projects.