Forum Discussion

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

Intel CFI Flash & HAL drivers

Hi,

I'm porting some code to our target board which uses the HAL to save settings in Flash. The code works just fine on the Stratix dev. kit board, but fails to program the flash on my target board.

What's different? The target has an 8MB Intel Strataflash CFI part in place of the AMD part. It's a 16-bit part, but is used in an 8-bit configuration (#BYTE Low - and yes, I have NIOS SDK 1.01). I'm also aware that the parthas 64 128K sectors rather than 128 64K sectors.

What works? The device can be programmed with "nios2-flash-programmer" command line, and the system boots and runs. Once running, the HAL seems happy with the CFI query information, and has correctly worked out the device type and architecture.

What goes wrong? I'm using the standard HAL calls to open/write/close the flash device. I open it OK, but the write fails. At first, I was getting a 'command sequence error' status from the flash (0xB0) when HAL tried to unlock the sector. This seemed odd, as the sector shouldn't be locked in the first place. I think the HAL code to read sector 'locked' state is accessing the wrong flash location (should be "block_offset+4" instead of +2, as A0 is ignored)

Having fixed that, I now get the "command sequence error" status while trying to erase the flash block http://forum.niosforum.com/work2/style_emoticons/<#EMO_DIR#>/sad.gif - the code looks fine, and the hardware does appear to be otherwise working OK.

Does anyone have any suggestions - and has anyone else successfully used the HAL drivers to write to Intel Strataflash CFI devices?

- Roddy

8 Replies

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

    hi,

    You use another flash, so

    which flash componet in SOPC Builder do u add for your own target board?

    Or else, How u create your own componet? tell me some instructions or Notice, please. I was confused by class.ptf and something else.
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    21 years ago

    Just the standard "External Flash (CFI)" component, set to 23 bits addr, 8 bits data, and very conservative timings.

    The actual part is a Micron MT28F640J3, but even the CFI reads back as an Intel part and Intel algorithm.

    As long as your flash part supports CFI and either AMD or Intel programming algorithm, that *should* be all you need to do.

    - Roddy
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    21 years ago

    Roddy,

    There was a problem with using 16 bit parts in 8 bit modes. This was fixed in the 1.01 release
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    21 years ago

    I&#39;m using the 1.01 release. Having singlestepped through stuff, I believe the following line# 160 in alt_unlock_block_intel.c is wrong: 

      locked = IORD_8DIRECT(flash->dev.base_addr, block_offset + 2);

    ... and should be... 

      locked = IORD_8DIRECT(flash->dev.base_addr, block_offset + 4);  // Was 2 - RJP

    I think this applies to 16 and 8-bit modes, but I&#39;m not sure.

    Anyway, even having changed that, I&#39;m still getting &#39;command sequence error&#39; status. But now in "alt_erase_block_intel" rather than "alt_unlock_block_intel"

    My original question still stands: Has anybody used the HAL successfully to rewrite sections of Intel (and compatible) flash parts??

    - Roddy
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    21 years ago

    Ooops Sorry Roddy I should read more carefully before posting. In short the answer to your question is yes the Hal drivers have been tested on a Strata Flash specifically the Intel 28F320J3.

    I&#39;m a little confused about the statement that A0 is ignored I&#39;ve just looked at the datasheet of the Intel part and cannot find that statement though it&#39;s a little ambiguous about whether it&#39;s using word or byte addressing so I&#39;ll have a look at the part. Where did you read this?

    For your information we unlock all the sectors, just in case someone has locked them, we have no way of knowing what people may have done to their flash.
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    21 years ago

    From the "Intel StrataFlash® Memory (J3) 28F256J3, 28F128J3, 28F640J3, 28F320J3 (x8/x16)" datasheet. [Order Number: 290667-020 November 2004],

    Section "10.2 Read Identifier Codes" Page# 39, Note 1:

    <div class='quotetop'>QUOTE </div>

    --- Quote Start ---

    NOTES:

    1. A0 is not used in either x8 or x16 modes when obtaining the identifier

    codes. The lowest order address line is A1. Data is always presented

    on the low byte in x16 mode (upper byte contains 00h).[/b]

    --- Quote End ---

    It&#39;s a bit bizarre, but that&#39;s what is says. It also seems to be what it does... The original code got an &#39;unlock status&#39; of 0x17 (Which is the identifier byte for a 64MB part). This gets interpreted as "locked". For a 32MB part - which you&#39;ve tested with, you&#39;ll read 0x16, which is interpreted as "unlocked" http://forum.niosforum.com/work2/style_emoticons/<#EMO_DIR#>/sad.gif , so your code may fail to unlock blocks on 32MB parts...

    Thanks for the confirmation that this style of part is supported/tested. I&#39;m sure the above bug (assuming it is a bug) isn&#39;t behind the problems I&#39;m having.

    I need to look much closer at our implementation!

    - Roddy
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    21 years ago

    Roddy,

    You&#39;re quite correct I just checked this on one of our test boards. The device code was 0x16 which is intepreted as unlocked. So yes there is a bug which which will on some parts prevent the unlocking of some blocks.

    That said though the chip programmed happily so there is no generic problem with Strata parts.
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    21 years ago

    http://forum.niosforum.com/work2/style_emoticons/<#EMO_DIR#>/biggrin.gif I&#39;ve now fixed the problem - but the resolution may be useful to others.

    When you do any erase/program/lock/unlock operation on an Intel flash chip, the HAL checks the status register to verify correct operation, which works fine. But one poorly documented aspect in the Intel datasheet is that any error bits in the status register remain set until you do a "Clear Status Register" (0x50) command. The HAL never does this, which may be an issue if an erase or program ever fails.

    Probably the CPLD boot sequence on our board performs spurious writes to the flash, setting the "Command Sequence error" bits. Because they&#39;re never cleared, all my subsequent programming attempts were failing.

    I&#39;ve added a "Clear Status Register" command at the beginning of the Erase Block code, and everything now seems to be working fine.

    Onwards and upwards....

    -Roddy