Programmable Devices
CPLDs, FPGAs, SoC FPGAs, Configuration, and Transceivers
Need Forum Guidance? Click here

Search our FPGA Knowledge Articles here.
19335 Discussions

MAX10/DE10-Lite board : SDRAM(64MB) problem downloading elf-file

Honored Contributor II

Hi All, 

I am using the DE10-Lite board with Quartus version 16.1. My application is running without any 

problems on a DE1 board (8MB SDRAM), on a DE0-Nano board(16MB SDRAM) and on a BeMicro CV board  

which is no longer available, so I decided to use the DE10-Lite board.  

I have created a minimal configuration to narrow the problem. Enclosed, please find the 

Qsys file. If necessary, I can provide the whole project as zip-file. 

The program is running without any problems if only the onchip_memory is used, see 1). 

The problem occurs if using the SDRAM only.  


1) ok, using onchip_memory 

Downloading 01000000 ( 0%) 

Downloading 01010628 (95%) 

Downloaded 66KB in 1.1s (60.0KB/s) 


Verifying 01000000 ( 0%) 

Verifying 01010628 (95%) 

Verified OK  

Starting processor at address 0x01000230 


2) ERROR , using SDRAM 

Downloading 04000000 ( 0%) 

Downloading 040105B4 (95%) 

Downloaded 66KB in 1.1s (60.0KB/s) 


Verifying 04000000 ( 0%) 

Verify failed between address 0x4000000 and 0x400FA63 

Leaving target processor paused 


I already tried different possibilities to solve the problem and followed also the hints 

and examples in the DE10-Lite_v.2.0.0_SystemCD but without success. I also tried to use 

the Nios II (Classic) -E Processor with external PLL : same problem. I am using the 

Single Uncompressed Image (3584Kbits UFM) Device option. At the moment, I am only able to 

start the program from the onchip_memory, so I tried to get access to my data which is 

based on a 48 MB union by changing via NiosII-BSP Editor the mapping from the .rwdata to 

the SDRAM. Unfortunately I have no experience how to do that correctly and I did run in  

a lot of other problems, probably my fault. It would be nice if someone can help me. 

In general, however, it only makes sense if the SDRAM is working correctly and I  

suspect that the problem is based in the RESET timing ? 

Every reference is welcome. Many thanks in advance, Reinhard
0 Kudos
1 Reply
Honored Contributor II

In the meantime, I have solved the problem by myself. 

It was related to the PINs DRAM_UDQM and DRAM_LDQM.  

These pins have always been incorrectly created / designated (in version Quartus 16.1) 

in a Qsys "Generate HDL ..." I changed it as follows: 


# DRAM_LDQM,Unknown,PIN_V22,5,B5_N0,3.3-V LVTTL,,4ma,,, 

# DRAM_UDQM,Unknown,PIN_J21,6,B6_N0,3.3-V LVTTL,,4ma,,, 

DRAM_dqm[1],Unknown,PIN_V22,5,B5_N0,3.3-V LVTTL,,4ma,,, 

DRAM_dqm[0],Unknown,PIN_J21,6,B6_N0,3.3-V LVTTL,,4ma,,,