Nios cannot open/access EPSC

Altera_Forum · ‎09-03-2013

Custom Cyclone IV based board. Uses EPCS16 (ST 25P16) for AS configuration of FPGA. Board successfully configures from the EPCS and will then boot Nios, also from the EPCS.

However, Nios cannot subsequently open the EPCS, as tested with sample code lifted directly from the 'Nios II Software Developer's Handbook'. This permanently reports it cannot open the device.

Function called:

alt_flash_open_dev( EPCS_0_NAME );

Always returns NULL.

All relevant Dual-Purpose Pins (DCLK, Data[0], ASDO, nCSO) are defined as 'Use as regular I/O' after programming.

Relevant section of system.h :-

/*

* epcs_0 configuration

*

*/

#define ALT_MODULE_CLASS_epcs_0 altera_avalon_epcs_flash_controller

#define EPCS_0_BASE 0x9000

#define EPCS_0_IRQ 0

#define EPCS_0_IRQ_INTERRUPT_CONTROLLER_ID 0

#define EPCS_0_NAME "/dev/epcs_0"

#define EPCS_0_REGISTER_OFFSET 1024

#define EPCS_0_SPAN 2048

#define EPCS_0_TYPE "altera_avalon_epcs_flash_controller"

Hardware does not have any external RAM to put to use, only RAM internal to the FPGA. So, testing the EPCS using Altera's 'Memory Test' software template is not possible as its code size is too big. 'Memory Test Small' will run, but doesn't test any flash.

Running QuartusII 64-bit 12.1 SP1

Altera_Forum · ‎09-03-2013

I very much doubt you'll manage to use the altera higher layer HAL functions to access the flash without having external memory.

I suspect that the read() and write() pull in all of stdio (as does printf) - so your minumum code size will be over 70k, never mind how much space you need in the heap (for malloc/free).

Also a quick look at the flash write() code shows that it will erase the entire flash segment if the data you are writing differs from that already programmed (not if the write would need to set any bits). So you'll need to write entire flash sectors in one write() call - which needs a 256k byte buffer if you have EPCS128 - you are unlikely to fit that it either.

I also suspect a 100MHz nios could directly bit-bang the EPCS device with 60ns per bit (write) and 80ns (read) with minimal interface logic or code.

Altera_Forum · ‎09-03-2013

I understand, although I'm a little disappointed at the lack of console messages in Eclipse whilst building the software. Other template applications clearly identify that they require more RAM than is specified in the .sopcinfo file. I'd have thought this would be easily identifiable during compilation.

I will resort to writing my own hdl implementing the commands required (rather than bit bashing). I do not need any form of read-modify-write. So, a simple bulk erase followed by the required page writes will suffice. No need for any large buffer to store a sector.

Many thanks

Altera_Forum · ‎09-03-2013

Dunno - that may not be why it is failing ....

Probably worth implementing sector erase, that takes a few seconds - so the user can be given progress info.

I don't think there is a significant speed up from doing a 'whole device' erase.

Altera_Forum · ‎09-06-2013

Final note...

I have now implemented some hdl to perform the low level interface to the EPCS. Combined with a little code running on Nios I can successfully read, write and erase sectors, all that I need it to do. FYI, the sector erase (512kb in the EPCS16) takes just under 1 second.

I'm still a little confused/disappointed with Eclipse as to why Altera's IP for the EPCS doesn't want to let me access it from Nios. Any further thoughts from anyone would be welcome.

Altera_Forum · ‎09-06-2013

Since the HAL code is all issued in source form, you could add debug code to see where it fails.

Although the code you have written is likely to have a much smaller footprint than the Altera functions.