Forum Discussion
Altera_Forum
Honored Contributor
8 years agoThank you for responding to my question - I carefully checked your points.
do you mean that you reset the pll when pressing the reset button? My setup consists of a Cyclone 4 (EP4CE6E22C8N) , SDRAM and a 7segment display array. One button is assigned to "reset wire". The verilog script looks as follows:
SDRAM_PLL (
~reset_wire, // assigned to a key
clk,
sdram_clk_wire,
sdram_we_n, //patched to sdram_clk,
cpu_clk,
PLL_locked);
simpleNIOS_Test (
cpu_clk, // clk.clk
PLL_locked, // reset.reset_n
sdram_clk_wire,
sdram_addr, // .addr
sdram_ba, // .ba
sdram_cas_n, // .cas_n
sdram_cke, // .cke
sdram_cs_n, // .cs_n
sdram_dq, // .dq
sdram_dqm , // .dqm
sdram_ras_n , // .ras_n
sdram_clk, // sdram_we_n externally patched to sdram _clk wire,
PIO_out,
PIO_in
);
* sdram_clk was unfortunately not wired to a dedicated clk output of the FPGA so I externally patched this accordingly as required (please have a look for my other post) The NIOS Setup looks as follows: (see my attached screenshot). https://alteraforum.com/forum/attachment.php?attachmentid=14004&stc=1 in that case you won't send a clock signal to the sdram when reset is pressed and if it is for a too long time it will probably cause refresh problems and it's not guaranteed that the contents of the sdram will survive the reset. To investigate whether the SDRAM contains working code after reset I programmed the NIOS via onchip and wrote a code that allowed for copying the entire code itself into the sdram if reset + button A was pressed. If reset + button B was pressed then the stack pointer jumps to sdram and executes the code placed on this location. (The reset button was released while either button A or B was still pressed)
int main()
{
unsigned char ledstate;
unsigned int PIOout_BASE_ADDRESS = 0x00805030;
unsigned int PIOin_BASE_ADDRESS = 0x00805020;
unsigned int memory_base = 0x00400000;
unsigned int memory_base_end = 0x00403fff;
unsigned int memory_base_onchip = 0x00802000;
unsigned int memory_base_onchip_end = 0x00803fff;
volatile unsigned int count;
volatile unsigned short int internalcount;
volatile unsigned int * PIO_out = (unsigned int *) PIOout_BASE_ADDRESS;
volatile unsigned int * PIO_in = (unsigned int *) PIOin_BASE_ADDRESS;
volatile unsigned int * memory = (unsigned int *) PIOin_BASE_ADDRESS;
//2^7 2^6 2^5 2^4 | 2^3 2^2 2^1 2^0
// 0 0 0 0 | 0 0 0 1
// 0 0 0 1 | 0 0 0 1
//0x0080_5020
volatile unsigned int content;// = 0x1234;
bool copied;
content = 0x0000;
displaytoLED(content);
if(!( *(PIO_in) & (1<<1) )) { //Key A
internalcount = 0;
for(count = memory_base; count < memory_base_end; count+=2) {
IOWR_16DIRECT(count, 0, IORD_16DIRECT(memory_base_onchip,0));
if(IORD_16DIRECT(count, 0) != IORD_16DIRECT(memory_base_onchip,0)) {
content = 0xFFFF;
displaytoLED(content);
}
else {
content = 0xAAAA;
displaytoLED(content);
}
memory_base_onchip+=2;
internalcount++;
}
while(!( *(PIO_in) & (1<<1) )); //Key B
content = 0xCCCC;
displaytoLED(content);
}
if(!( *(PIO_in) & (1<<0) )) {
content = 0x1111;
displaytoLED(content);
while(!( *(PIO_in) & (1<<0) ));
((void (*) (void)) 0x00400000) (); //jump
}
while(1);
return 0;
}
The success of each action is displayed by the 7 segment array. It turned out, that SDRAM contains a working code after reset because the display changed as expected from "1111" to "0000" (it displays the hex digits as given in the code). Thus I conclude that either the nios or the sdram controller is malfunctioning. is the cpu's reset vector set to the sdram? For programming the nios using the sdram I change of course the nios setting RESET and EXCEPTION vectors to sdram_controller and I also use the BSP editor to verify the linker script. i assume that memory_base is the address of the sdram? in that case by writing something at that base address, you overwrite the reset vector, probably causing the cpu to crash at reset. This is correct but I use another code to verify whether it is still working after reset (hello world app). Since I am (was) a beginner "hello world" was actually what I tried at first and unfortunately after reset it refused to work in case the code was programmed to sdram. If there are no other suggestions I will try to implement an exception handler to e.g. gain some more information on what is going on after reset in case the sdram is used as the program memory. If I made somewhere a mistake please be so kind and give a hint. *Edit: Regarding the problem that after reset the NIOS hangs if SDRAM is used as the program memory I meanwhile observed the same problem in case the terasic DE2 (Cyclone2) demoboard is used – thus it might be something general associated with programming of the FPGA rather than external wiring of the setup.