Forum Discussion
Altera_Forum
Honored Contributor
Honored ContributorRUN AS HARDWARE error
After I install Quartus5.0 Nios5.0,I find these errors comes out frequently.
Using cable "ByteBlasterII ", device 1, instance 0x00
Processor is already paused
Reading System ID at address 0x02000908: verified
Downloading 01000020 ( 0%)
Downloading 01010000 (98%)assertion "m_state == STATE_DEBUG" failed: file "nios2
debug.cpp", line 1695
Signal 6Using cable "ByteBlasterII ", device 1, instance 0x00
Pausing target processor: not responding.
Resetting and trying again: assertion "m_state == STATE_DEBUG" failed: file "nio
s2oci.cpp", line 226
Signal 6Using cable "ByteBlasterII ", device 1, instance 0x00
Processor is already paused
Reading System ID at address 0x02000908: verified
Downloading 01000020 ( 0%)
Downloading 01010000 (96%)
Downloaded 67KB in 1.9s (35.2KB/s)
Verifying 01000020 ( 0%)
Verify failed
Leaving target processor paused13 Replies
Altera_ForumMake 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- Altera_Forum
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 . - Altera_Forum
Does your reset address point to volatile memory such as DRAM?
- Altera_Forum
I reset address point to external Flash.
- Altera_Forum
Try slugging the TCK line with 33pF.
- Altera_Forum
The Byteblaster-II is designed and laid out very differently to Byteblaster/Byteblaster-MV (which were based around a 74244).
I'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's the best reasoning I can conjure - I have experienced double-triggering on Cyclones that I didn't get on MAX devices before). I'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'm pretty sure most memory devices can handle being operated in this way. - Altera_Forum
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? - Altera_Forum
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'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. - Altera_Forum
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!! - Altera_Forum
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 ?
