• State Resolved
  • Locked Locked
  • Replies 3 replies
  • Subscribers 98 subscribers
  • Views 622 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

C6748 SPI Flash for custom board

David Luca
Expert 2795 points
Other Parts Discussed in Thread: OMAPL138, OMAP-L138

Hello,

We've been using successfully the sfh_OMAPL138 flash writer with the EVM from LogicPD to write bootable images which work with the DSP module.

Command that was used is: sfh_OMAP-L138.exe -flash_noubl myappc6748.ais -p COM1 -flashType SPI_MEM

We designed a custom board based on the DSP module(24MHz crystal)  but since the EVM's SPI flash is difficult to find through our distributors we used an Atmel flash chip which supports the read command with 03h and 24bit addressing(AT25DF641) as specified in http://www.ti.com/lit/an/spraat2e/spraat2e.pdf that is connected to SPI1 [CS0]. UART boot pins are set for 115.2kbps so that we see "BOOTME" when board is reset. The problem we have is sfh_OMAPL138 SPI writer application when executed manages to erase the flash successfully and uploads the code but verifying fails and it doesn't work.

What flash chips are compatible with this processor and bootloader software which are not yet obsolete? Any idea why this Atmel chip wouldn't work and where should I start looking for the problem? This Atmel chip apparently is supported forever so it would be better for us to use it.

Thank you in advance for any suggestions,

David.

  • 0
    Intellectual 325 points

    I ran into the same problem.  We worked around it short term by finding a small number of the ST parts that worked, but as we get closer to needing volume we need to address this issue.  Has there been any resolution?  A list of parts that work?  A recommended fix for the atmel part?

    Thanks,

    Seth

  • 0 in reply to Seth Dziengeleski
    Intellectual 325 points

    I think I just answered my own question.

    In section "8.3 Protect Sector" of the Atmel data sheet it states that "Upon device power-up, each Sector Protection Register will default to the logical "1" state indicating that all sectors are protected and cannot be programmed or erased."

    The data sheet for the flash I had previously used (Numonyx M25p64 part) states in section "8 Initial Deliver State" that "The device is delivered with the memory array erased: all bits are set to 1 (each byte contains FFh). The Status Register contains 00h (all Status Register bits are 0).".  Reading the status register description shows that @ 00h all block protection bits are in the unprotected state.

    I've got samples of a Macronix MX25L25635E that uses the same foot print as the Numonyx and Atmel Parts.  They are arriving tomorrow and are delivered unprotected like the Numonyx part.  I suppose I could alternatively crack open the source of the sfh utility and add steps to clear the protection bits in the Atmel flash part to solve this issue as well.  Buying a different flash part seemed easier and I wanted a larger capacity anyway.

    I let you know how the new part works out for me.

  • 0 in reply to Seth Dziengeleski
    Expert 2795 points

    Hi Seth,

    Thank you for investigating this further, because of the time required to learn the sfh flashing and the firmware tools we abandoned this flash type in favor of S25FL064K0SMFI011 (8MB) from Spansion which works fine and seems to be available, but I'll keep in mind what you've found and implement the changes in future if we decide/need to go back to Atmel chip. Personally I don't see the point of protecting in factory an empty flash. 

    Best regards,

    David.