using epcs flash for both reset vector and store configuration

I used this feature with 9.0 sp2 and it works.

Make sure you set the epcs pins with the "Use as regular i/o" option in Quartus project settings, otherwise fpga configures but Nios couldn't access epcs because those pins were reserved.

The fpga pins are configured correct (I assume) because I can program the flash memory using Nios Flash programmer. My problem occurs when I try to open the flash in the Nios program using

fd = alt_flash_open_dev("/dev/epcs_controller");

The file descriptor is NULL.

I know it works. You FPGA qsys (or SOPC builder) system must have the epcs_controller built into it. If it's not present, it won't work.

Pete

I found the problem. In the NIOS configuration, I was using the "reduced device drivers" option. Without this option, I get a non-null file descriptor.

Although I made the inclusion presented in the embedded ip user guide to force including the api's for flash controller, it still doesn't work with "reduced device drivers".

At this moment I'm using the following inclusions:

# define ALT_USE_EPCS_FLASH
# include <stdio.h># include <io.h># include "system.h"# include "sys/alt_irq.h"# include "sys/alt_flash.h"# include "sys/alt_flash_dev.h"# include <altera_avalon_epcs_flash_controller.h># include "define.h"  
 

Now, disabling the "reduced device driver" option, I could do more tests for my project. I intend to remotely configure some parameters of the device, so the configuration data stored in the flash will change from time to time, without changes to the FPGA sw and hw (only one page of the flash will change). But, after a change is made and I want to reboot the device (power off/on) the FPGA won't configure itself. I presume this has something to do with the check-sum that the flash programmer calculates and writes on the end of flash.

Is there a possibility to use the same flash for firmware and exchangeable configuration data ?

You need to make sure that you are writing to a different flash sector from those that are loaded at boot time.

When I looked through the altera flash driver code it really wasn't the functions I was looking for!

The internal low-level functions might be useful, but the outer level ones the application is expected to use are hopeless.

Apart from all the extra layers of code, the big fubar is that it won't let you write to part of a flash sector without erasing the entire sector.

It really should allow the write if the old data is all 0xff (more particulary if the write only needs to clear bits), otherwise you need a 128k memory block to do your own RMW cycle. If you have to use internal memeory that is a lot of the devices memory.

Thank you dsl for your answer!! I forgot a 0 on the end of the offset, so I was writing in the boot sector.

At the moment I only have the first problem, I can't use the flash with the "reduced device driver" option turned on.

If you look through the HAL sources you'll find the low level functions that actually do the read/write/erase actions (by driving the SPI block).

You should be able to compile those files and then directly call the functions.

The smallest fpga resource use probably comes from defining an avalon slave that directly accesses the epcs SPI signals and then directly bit-bashing them.

The SPI interface hardware might be faster for reads, but for writes and erases the time spent waiting for the operation to complete dominates.

Some quick design (assuming little-endian data):

struct spi_bang {
    volatile uint32_t spi_data_low:  /* write low bit with clock low. */
    volatile uint32_t spi_data_high; /* write low bit with clock high. */
    volatile uint32_t spi_control;   /* chip select etc.*/
    volatile uint32_t spi_pad;
};

Then you write the same value to spi_data_low, spi_data_high and spi_data_low again before shifting right one bit and looping through the required number of bits.

With a 100MHz nios and assuming two clocks for each Avalon write an unrolled loop would need 7 clocks per byte - 14MHz.