Flash Access Problems

[Altera_Forum]

We have a 3 processor design that all boot successfully from a single CFI flash (all reset addresses are set to our CFI Flash at different addresses). The firmwares run in different On Board Memories. Our design has worked successfully for a number of weeks on a number of different boards.  

 Recently we have seen the following fault on 2-3 different boards on different occasions :-once all 3 CPUs have been loaded and our single main CPU runs the following function    handle = alt_flash_open_dev(CFI_FLASH_NAME); if (handle == 0) {//Open Failed   with following define is from system.h file   #define CFI_FLASH_NAME "/dev/CFI_Flash"   The function alt_flash_open_dev fails    in addition, when downloading using flash programmer from eclipse compiler the download fails with error "CFI table not found"   We do not use "reduced device drivers" option in the BSP We are using Quartus II Ver. 10.1  Can anyone give some help on this

[Altera_Forum]

The flash should be initialized if the following is true. 

# if (!defined(ALT_EXCLUDE_CFI_FLASH) && ((!defined(ALT_USE_SMALL_DRIVERS) && !defined(ALT_SIM_OPTIMIZE)) || defined(ALT_USE_CFI_FLASH)))  The easy way to ensure this is to just define ALT_USE_CFI_FLASH. In the BSP Properties under NIOS II BSP Properties add "-DALT_USE_CFI_FLASH" (without quotes) to Defined Symbols.  I have problems when I have two BSPs for the same processor, but I am sure that is different than your situation.  There is a global device list that should be filled out when alt_main() executes. Watch the global alt_flash_dev_list as you step through alt_main().  Since you are using three processors and I will be in the future, I have a question for you. I have seen some people saying that they cannot debug three processors at once, have you experienced this problem?

[Altera_Forum]

If you are accessing the flash right at the beginning of your main(), there may be a variance from board to board that is causing the problem. I am not sure exactly what causes it, but my best guess would be the rise time on a capacitor. On the current board that I am working with I have to wait 20us before I access the flash.

[Altera_Forum]

You might need to do some inter-cpu locking to stop more than one cpu accessing the flash hardware at the same time. Without that I suspect that some operations will fail badly. 

I don't know what the open() does - nor really understand why altera map things like flash accesses onto unix (posix) files.

[Altera_Forum]

DSL, 

I am under the impression that all accesses to the flash are handled by the arbitration mechanism with the SOPC builder system - if so why would I need "some inter-cpu locking to stop more than one cpu accessing the flash hardware at the same time" ??   Another question : Is it possible for the CFI table to be become corrupted ? I saw in the Flash Programmers guide from Altera the following :-   "Nios II Flash Programmer provides the ability to override CFI table entries with flash override files. A flash override file lets you manually override erroneous information in the CFI table, which enables the Nios II Flash Programmer to function correctly "   Can conclude from this that the CFI table could be corrupted ? If so how does this hapenn and how do I fix it ? Also is there anyway to protect the CFI table so that it can't hapenn again ?

[Altera_Forum]

The SOPC builder (etc) arbitrates each individual bus cycle. 

This is ok if all you are doing is reads. If you start doing writes and erases you need to ensure that no other accesses happen during the entire write/erase procedure. A sector erase is likely to take a significant fraction of a second.

[Altera_Forum]

DSL, 

Thanks for that important peice of info. Tell me will a MUTEX component help me with this type of control ????   Thanks   Shmuel

[Altera_Forum]

Dunno - I'd just open-code Dekker's algorithm in shared (uncached) memory. 

Especially since you might want a 'trylock' action...

[Altera_Forum]

dls, 

Sorry I didn't understand your answer can you please elaberate ?   Thanks    Shmuel

[Altera_Forum]

Dekker's algorithm is a way of implementing a mutex without requiring locked bus cycles (it does need a simple bus interface - which the nios2 has). It is quite simple to write, and can be tuned to have exactly the required semantics.

[Altera_Forum]

DSL,  

Thanks for the further explanation. It sounds like you are a referring to some sort of firmware\software solution\control ?! Where can I find more info on this ?    I was referring to the MUTEX component within the SOPC system, that I came across in the past but never really looked into......   Thanks again    Shmuel

[Altera_Forum]

google :-) (dekker mutex) 

I've not looked at the sopc mutex component either, I've seen code snippets on here that might be trying to use it - but the interface seemed gross (via open() etc). I can imagine implemeting mutex in a logic block with multiple Avalon slaves (one for each master) where a write of '1' would stall writes on the other slaves (ie from the other masters) until a write of '0'.