Showing results for 
Search instead for 
Did you mean: 
Honored Contributor I

Assembly + Nios + two cores

hi, this is sundaram from University of Waterloo. I have a quick question. I have a design where there are two cores and they both have executable sections on the ddr2 sdram which, is connected through a pipeline bridge. what I'm trying to do is very simple. 


The code for the first goes something like this : 

#include "stdio.h" int main() { __asm__ ("movhi r1,%hi(0x08000020);ori r1,r1,%lo(0x08000020);jmp r1"); return 0; } 


and the code for the second core goes something like this: 


#include "stdio.h" int main() { printf("I hope it works!"); return 0; }  

The ram is divided like the first half for the first cpu and the second half for the second cpu. In fact 0x08000020 is the entry section for the second core. So, I downloaded both the programs to their respective locations and executed the first program. However, I didn't get any output. If someone knows the reason to this, please let me know immediately. 


0 Kudos
2 Replies
Honored Contributor I

you could try to light a LED in the software, the operation is simpler and less prone to problems. 

Do the first CPU have access to the jtag uart? are you opening the nios console on the correct connection? 

You could run with a debugger step by step to check if the CPU does what you intended it to.
Honored Contributor I

Where are the reset vectors for the 2 processors? 

Are you using the JTAG loader for both?? 

(Does this actually work - I've not really used the JTAG loader except for some very simple tests.) 

When the sopc system comes out of reset both cpu will start executing from their own reset vectors - if both can run in their own copy of the jtag loaded this would be ok. 


If you want the 2 cpus to work together, you can expose the 'soft reset' for the 'slave' cpu (and have it sit soft-reset when the sopc reset is removed), have the main cpu's initialisation load all the code then release the slave cpu from reset. 


As Daixiwen said, using the LEDs is much better than printf for low level debug. However you the avalon slave interface to the LEDs probably isn't ideal. It is much more useful to have 2 registers, writes to one turn the LEDs on, and writes to the other turn them off. That way multiple CPUs (and interrupt routines) can set/clear individual LEDs without having to do read-modify-write sequences. 


If you have test switches on the board, a 'read switch' 'write LED' loop is a very simple way of verifying that a processor is running.