Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Altera_Forum
Honored Contributor I
694 Views

simple change nios2/s -> /e fails to load pgm

just getting started with de1  

i presumed a simple change from niosII/s -> niosII/e in the count_binary  

example of the hardware tutorial would compile /load/ run with no surprises  

 

the program runs fine using niosII/s  

 

but if i downgrade the processor nios2/e-the program fails to load- 

 

with the unhelpfull message that appears in the forums over & over  

 

pausing target processor: not responding. 

resetting and trying again: failed 

leaving target processor paused 

 

at roughly 65% complete ... 

 

.. what am i missing ??
0 Kudos
5 Replies
Altera_Forum
Honored Contributor I
17 Views

Does the project meet all timing requirements when you compile it in Quartus? The nios2/e core has less pipelining than the /s core IIRC and its fmax could be lower.

Altera_Forum
Honored Contributor I
17 Views

 

--- Quote Start ---  

Does the project meet all timing requirements when you compile it in Quartus? The nios2/e core has less pipelining than the /s core IIRC and its fmax could be lower. 

--- Quote End ---  

 

 

i had tested the both (s&e) at both 50Mhz & 25Mhz  

& no - timing had no negatives
Altera_Forum
Honored Contributor I
17 Views

The core change can't explain your problem alone... can you switch back to the /s core, regenerate, recompile and test again? Just to be sure this isn't due to a bad pin assignment. 

Check also that your two systems have the same parameters (especially reset vector and exception addresses) and use the same clock domains.
Altera_Forum
Honored Contributor I
17 Views

I had discovered a 'bad pin' the first time round which got the /s working  

moving back to /e the upload still fails - been back and forth a couple time with small tweeks - /s yes, /e no  

going to try with the "legacy" tool chain tonight 

NOTE: the fpga always installs, just loading the prgm for Nios2 fails
Altera_Forum
Honored Contributor I
17 Views

did you compare the reset and exception addresses between the two cores? 

if you are using cache memory on the /s core, disable burst accesses, if it is enabled