RUN AS HARDWARE error

Make sure your unused pins is set to 'all input, tri-state';

I used to come cross such problems which can be prvented in this way.

It's not the fault of qt5.0.

http://forum.niosforum.com/work2/style_emoticons/<#EMO_DIR#>/sleep.gif

The fact :

1. Using ByteBlasterII will cause those error.

2. Using ByteBlasterMV turn out OK!

I think it is the problem of "RUN AS" of Nios IDE .

The Byteblaster-II is designed and laid out very differently to Byteblaster/Byteblaster-MV (which were based around a 74244).

I&#39;ve ended up slugging all of the JTAG signals (each with 33pF); I suspect that crosstalk from the TDI/TMS signals is occuring when the TCK signal goes low thus causing false clocking (which could be complete ballerks but it&#39;s the best reasoning I can conjure - I have experienced double-triggering on Cyclones that I didn&#39;t get on MAX devices before).

I&#39;ve also widened the SRAM timings (ridiculously long for now - like 50/100ns)

Also make sure there are no other devices on the bus fighting the SRAM when the JTAG debug module is trying to program it.

One thing I did notice is that a 32-bit word write on a 16-bit device is done with 2 write pulses, but with chip select asserted throughout, with the A1 change between the write pulses. The reads are done with separate chip selects. I&#39;m pretty sure most memory devices can handle being operated in this way.

hi mountain8848,

you said " The fact :

1. Using ByteBlasterII will cause those error.

2. Using ByteBlasterMV turn out OK!

I use byteblasterMV to try the run... function, but the niosII display jtag device can not surport this download cable, maybe the cyclone device only surport byteblasterII or usb blaster, how do you use byteblasterMV as a jtag cable?

We had these messages very often too ... no cap no resistor helped. signaltap worked but flashprogrammer failed.

The only solution we had to permanently fix this was to creat a new sopc target design from a clean folder.

I don&#39;t know if you have moved from Q4.2 to 5.0 like we did. But here the SOPC target folder was created with Q4.2SP1 and then the design moved to Q5.0. we recompiled the sopc target with q5.0 but nothing fixed this mess.

So try to create a complete new sopc target "mktarget....." with Q5.0 .. here this messages never appeared again.

my project worked well in quarutsII 4.1 + niosII 1.0, and then I can download a big file to flash in quarutsII 5.0 + niosII 5.0!

so your problem is not same as mine!

but I can only run hello_led, and not run hello_world in condition of quartusII 5.0 and niosII 5.0!

are there some changes in niosII 5.0??

very strange!!

hmmm just that i understand you right ...

you worked with q4.1 and nios 1.1 and then downloaded and updated to q5.0 nios5.0 , without a change in your design only just a recompile of the whole project ?