Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Altera_Forum
Honored Contributor I
1,665 Views

Flash Access Problems

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
0 Kudos
11 Replies
Altera_Forum
Honored Contributor I
52 Views

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
Honored Contributor I
52 Views

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
Honored Contributor I
52 Views

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
Honored Contributor I
52 Views

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
Honored Contributor I
52 Views

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
Honored Contributor I
52 Views

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
Honored Contributor I
52 Views

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

Especially since you might want a 'trylock' action...
Altera_Forum
Honored Contributor I
52 Views

dls, 

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

 

Thanks  

 

Shmuel
Altera_Forum
Honored Contributor I
52 Views

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
Honored Contributor I
52 Views

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
Honored Contributor I
52 Views

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'.
Reply