Design Issue when FPGA is configured from serial flash

[Altera_Forum]

Hi,  

 I am using Cyclone III FPGA to log some data from different analog channels. I have a strange problem with that. when jtag cable is connected everything is fine and working very well. however, when the fpga configures from serial flash, it only works for between 20 and 40 minutes and then stops working. I am using Nois II processor and three different SGDMAs and I have a valid license for Nios II. I have used this processor on many previous design and I have never had a problem. I know there are many parameters can cause the error but any comments will be much much appreciated.   many thanks in advance

[Altera_Forum]

Are you sure you are not using other unlicensed or time limited cores, besides the licensed Nios? 

With "jtag connected" do you mean: 1- simple cable connection  2- use jtag uart terminal 3- load the application in debug mode  Any of these can have a different explanation: 1- grounding or signal integrity problems 2- your application sends debug data through jtag uart: when the buffer fills up, this introduces some excessive delays which are fatal for your application 3- some part of the code behaves differently when compiled in release mode  I guess your situation is nr.2. I had a similar problem, although in my case it caused only an application slowdown during the execution of some tasks.

[Altera_Forum]

Maybe You have Nios license, but what about other cores? No TSE, SDI, etc?

[Altera_Forum]

i don't think you can convert a .sof into a non-volatile programming file if there is unlicensed IP in it

[Altera_Forum]

A yeah, just thought he still use JTAG :)

[Altera_Forum]

Hi guys, many thanks for precious ideas. I will go through it and will let you know. I think 2 ideas are making more sense. I have 2 different designs (Master and Slave) and I think the idea that JTAG buffer became full much make more sense. I will try it without using JTAG buffer and see what happens. I also keep the itag connected and It might be ground issues as well. I don't think so lacking of licence cause this problem as I have used the same IPs on many previous designs. I will let you know guys the outcome. any more ideas will be much much appreciated.

[Altera_Forum]

Just to be clear: you don't need to remove jtag debug module or changing buffer size.  

You simply have to remove printf calls from your code, especially those displaying lot of data and those called frequently.

[Altera_Forum]

Thanks again guys for fantastic comments. This forum is awesome. yes indeed that was the problem. I have different critical interrupts which should be handled and it seems printf when the jtag is not active and design is in release mode causes major delays and therefore we end up interrupt starvation in the system. I will leave the system to function today over the night to 100% make sure that was the problem. We designed a system couple of months ago and strangely Master system stopped functioning. it was strange as battery monitor unit showed that battery was fine. I think this was the problem and we will try to update the firmware. Thanks again for fantastic comments as it saves me lots of time and I don't know why I forgot disabling all debug command this time. so the lessons learned and the most important one is DON't START A NEW DESIGN AFTER 12 HOURS WORK ON ANOTHER DESIGN.:)

[Altera_Forum]

Just a general comment, it is best to avoid doing printf's in interrupt routines. First some i/o implementations use IRQ themselves and you could end up locking the system, and second ISR should execute as fast as possible, especially if you are looking for real time performance. printf's use lots of CPU cycles. 

A better way to print information from an ISR is to wake up a task that will do it once the ISR returns. (of course this only applies if you are using a multitask operating system).

[Altera_Forum]

Many Thanks, it noted.