Terasic DE2-115 Flash programming

Some additional info...

Compared flash file to what is actually stored in flash. They are the same. Therefore, I believe that the HW is functional.

Have read other posts. I do see quite a bit of discussion on Offsets. If I read the FLASH programmer guide it indicates that the ELF file should not specify an offset.

Am not specifying a SOF file in the NIOS Flash programmer as I loaded the POF through Quartus programmer. The board contains an EPSC for the FPGA as well as a CFI FLASH for the NIOS Application.

I usually make everything (both file conversion and programming) with the attached script file. This is faster and safer than the gui tools.

Simply change fpga and nios project names and epcs base address according to yours and run it in the Nios shell window.

If this won't work, you must identify where your problem is.

First of all make sure fpga configuration has been loaded from flash and it is operational:

1. check conf_done pin

2. use a counter to blink a led or any other output pin, or add some trivial logic in order to recognize the fpga has been correctly configured

In most cases the problem is with the next step: Nios bootloading.

Check if the correct bootloader has been included in Quartus project (you should have a epcs_controller_boot_rom.hex file here). Another common issue is a wrong reset address in Nios configuration, but you already checked this point.

Another problem can arise if your code sections are distributed across different memory devices (i.e. sdram, sram, onchip ram). When you load and debug with jtag, the debugger takes care of directly loading all memory sections with the proper code, while in the flash boot case this task must be accomplished by the bootloader or manually.

You may need to call ALT_LOAD_SECTION_BY_NAME(<section_name>) in the very beginning of your main().

Yes, I did...I use SOPC builder, so the instructions are specific to it rather than QSys

1) In SOPC builder modify your CPU component so the reset vector is set to CFI flash.

2) Generate the SOPC

3) Generate your system in Quartus.

4) In Eclipse, go to the BSP, right click and select BSP Editor

5) On the Main Tab, select Settings->Advanced->hal->linker. You'll see 5 components (allow_code_at_reset, enable_alt_load, enable_alt_load_exceptions, enable_alt_load_copy_ro_data, enable_alt_load_copy_rw_data). Disable ALL of these.

6) On the Linker Script Tab, ensure that your reset linker region is set to cfi_flash and all linker sections are set to sdram.

7) Regenerate your BSP

8) Load the ELF using the FLASH programmer.

If you look at Chatper 2 of the NIOS SW Manual, it goes into the details.

My experience with Altera tools is only about 6 months. I have found that the information is there. However, it is sometime a challenge for a newbie to dig it out. I'm sure the Altera Gurus know the documentation inside and out.

Hope this helps,

ME

Thanks for the step by step process Mark.

Ok, so I got my program working this morning, but in order to do so I had to slow down my UART. It looks like the program runs much faster in RAM 'Run as NIOS II Hardware' versus running out of flash.

Does anyone know if the boot process automatically loads the program into RAM upon startup? How do i use the command:

ALT_LOAD_SECTION_BY_NAME(<section_name>)

any examples on this?

Yes, the configuration I specified creates a boot loader (It is the section, "Booting from flash memory and running from volatile memory) in the reference material (link below, sorry it was the embedded design handbook, not the sw developers handbook). The documentation also specifies other configurations that might meet your needs.

http://www.altera.com/literature/hb/nios2/edh_ed_handbook.pdf

ME

Here is the section you are referring to:

--- Quote Start ---

Booting From Flash Memory and Running From Volatile Memory

If your application image is stored in flash memory, but executes from volatile memory with assistance from a boot loader program, prepare for BSP configuration by following these steps:

1. Nios II processor reset address—Ensure that the Nios II processor's reset address

is an address in flash memory. Configure this option using SOPC Builder.

2. Text section linker setting—Ensure that the .text section maps to a volatile

region of system memory, and not to the flash memory.

3. Other sections linker setting—Ensure that all of the other sections, with the

possible exception of the .rodata section, are mapped to volatile memory regions.

The .rodata section can map to a flash-memory region.

4. HAL C run-time configuration settings—Configure the BSP settings as shown in Table 2-3

Table 2–3. BSP Settings to Boot from Flash Memory and Run from Volatile Memory

BSP Setting Name Value

hal.linker.allow_code_at_reset 0

hal.linker.enable_alt_load 0

hal.linker.enable_alt_load_copy_rwdata 0

hal.linker.enable_alt_load_copy_exceptions 0

hal.linker.enable_alt_load_copy_rodata 0

--- Quote End ---

So if you set the linker .text to viotile memory, then how does it store the program code? Do you need to store a copy of it in flash and then dump this into viotile memory at boot-up?

The programmer actually creates a SREC FLASHable file that includes a bootloader. When you apply power, the bootloader copies your application from FLASH to volatile memory. When you run the programmer and select the BSP/SOPC file, you should see a reference to the bootloader in the elftoflash command line....

Basically, it's all taken care of by the tools.....

ME