Forum Discussion

Altera_Forum's avatar
Altera_Forum
Icon for Honored Contributor rankHonored Contributor
14 years ago

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

11 Replies

  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    14 years ago

    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's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    14 years ago

    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's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    14 years ago

    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's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    14 years ago

    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's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    14 years ago

    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's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    14 years ago

    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's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    14 years ago

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

    Especially since you might want a 'trylock' action...
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    14 years ago

    dls,

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

    Thanks

    Shmuel
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    14 years ago

    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's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    14 years ago

    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