Nios® V/II Embedded Design Suite (EDS)
Support for Embedded Development Tools, Processors (SoCs and Nios® V/II processor), Embedded Development Suites (EDSs), Boot and Configuration, Operating Systems, C and C++
12589 Discussions

NIOS SDRAM hang up after reset

Altera_Forum
Honored Contributor II
1,585 Views

Dear Forum, 

 

as I wish to use SDRAM as the main program memory for testing nios- code I don’t understand why this code works always only on times after download – after reset the nios hangs up. If I use the on-chip memory instead reset works as expected. As mentioned in many other threads I connected the reset button with the PLL (phase shift required to operate the sdram) and the pll-locked signal to the reset input of the nios. 

To understand this problem in more detail I used a small program to write something into the SDRAM if a phushbutton was pressed which then stayed in SDRAM after reset. Thus I would expect the entire hex dump will also stay there.  

void displaytoLED(unsigned short int result) { unsigned char ledstate; unsigned int PIOout_BASE_ADDRESS = 0x00805030; volatile unsigned int * PIO_out = (unsigned int *) PIOout_BASE_ADDRESS; ledstate = 0; ledstate = (result >> 0) & 0xF; ledstate += (1<<4); *(PIO_out) = ledstate; ledstate = 0; ledstate = (result >> 4) & 0xF; ledstate += (1<<5); *(PIO_out) = ledstate; ledstate = 0; ledstate = (result >> 8) & 0xF; ledstate += (1<<6); *(PIO_out) = ledstate; ledstate = 0; ledstate = (result >> 12) & 0xF; ledstate += (1<<7); *(PIO_out) = ledstate; } int main() { unsigned int PIOout_BASE_ADDRESS = 0x00805030; unsigned int PIOin_BASE_ADDRESS = 0x00805020; unsigned int memory_base = 0x00400000; volatile unsigned int * PIO_in = (unsigned int *) PIOin_BASE_ADDRESS; unsigned short int content = 0x1234; volatile unsigned short int result; if(!( *(PIO_in) & (1<<1)) && !button_pressed) { content = 0xABCD; IOWR_16DIRECT(memory_base, 0, content); content = IORD_16DIRECT(memory_base,0); displaytoLED(content); } else { content = IORD_16DIRECT(memory_base,0); displaytoLED(content); }  

 

I would be very happy If anybody knows why the nios hangs up after reset if the SDRAM contains the code .
0 Kudos
4 Replies
Altera_Forum
Honored Contributor II
433 Views

When you say that you connected the reset button to the PLL, do you mean that you reset the PLL when pressing the reset button? 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. 

Is the CPU's reset vector set to the SDRAM? 

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.
0 Kudos
Altera_Forum
Honored Contributor II
433 Views

Thank 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.
0 Kudos
Altera_Forum
Honored Contributor II
433 Views

What I was thinking about in my last point was that those two lines 

--- Quote Start ---  

content = 0xABCD; 

IOWR_16DIRECT(memory_base, 0, content); 

--- Quote End ---  

will overwrite the reset vector, causing the system to be unbootable is the CPU has its reset vector set to the SDRAM. Did you try without this operation? 

Otherwise the only way I can think about is to use SignalTap on the Avalon masters on the CPU and trigger after a reset to see what the CPU is doing when coming out of reset.
0 Kudos
Altera_Forum
Honored Contributor II
433 Views

Dear Forum, 

 

I’ve found the problem – it’s of course “homemade”. In my previous designs I used a second clk source as part of my nios setup (see the image in my previous post) however it turned out that there is no need to also feed the sdram controller with the phase shifted clk signal required for the sdram. After simply connecting the sdram controllers clk with the same clk as used for the nios reset works as expected. Just in case I am not the only one with that problem I’ve attached another screenshot of my nios setup.https://alteraforum.com/forum/attachment.php?attachmentid=14014&stc=1  

 

 

what i was thinking about in my last point was that those two lineswill overwrite the reset vector, causing the system to be unbootable is the cpu has its reset vector set to the sdram. did you try without this operation? 

 

To test sdram I executed the "hello world example" which is part of the eclipse wizard and what refused to work. The given code examples in my prev. post where only made for investigating whether the content stored inside the sdram can survive reset (which was indeed the case).  

Thank you
0 Kudos
Reply