• State
  • Locked Locked
  • Replies 11 replies
  • Subscribers 32 subscribers
  • Views 2503 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.

tm4c1294ncpdt and an external flash S25FL127S

Jane Doe
Prodigy 45 points
Other Parts Discussed in Thread: TM4C1294NCPDT

Hi,

I have a TivaC tm4c1294ncpdt and an external flash S25FL127S. The flash memory is connected via a SPI bus. I am able to read the ID, read and change the state of status and control registers. However, attempts to write to the main flash memory do not result in any changes of the memory block.

Does anyone have a working code example to write/read S25FL127S memory from Tiva? Similar code would also help.

Thank you!

  • 0
    Guru 13040 points
    Hello,
    If you are able to make it work all the way to actually reading the ID (and are sure about what you are getting is really such), then you're almost there...
    Spansion memories typically have write protect hardware signals (either controlled by a GPIO pin or hard wired to not-protected), block protection, and write enable command as well. Are you sure all these were unlocked?
    Cheers.
  • 0 in reply to Bruno Saraiva
    Prodigy 45 points

    Hi Bruno,

    Thank you very much for the quick and informative answer. I verified that WP# pin is HIGH (which disables write protection), block protection is off, and I verify that WEL is being set correctly. With that, the write operation should work. But what I am concerned about now is the READ operation. According to Spansion, the first 16 bytes of memory should contain a random number. However, when I read these bytes, I consistently get all 0xFF. This makes me wonder if the write operation works ok but the read operation fails and thus breaks my cross-check of what's written vs what's read.

    With that, do you think that my read operation is really broken? If so, how would you suggest to approach the debugging?

    The "Read Identification" command returns two bytes as expected and it uses a very similar logic.


    Regards,
    /Jane

  • 0 in reply to Jane Doe
    Guru 13040 points

    Sorry, we then enter into the realms of guessland... nothing other than patience and structured thinking will do - or hoping that someone else with the proper answer can help!

    Do you have a serial analyzed available? Can you see the signals between the MCU and the memory, and are they what you expected (first, on the MISO direction, then on the replies)? Add to the checklist: is the serial comm clock speed compatible? Did you read the memory datasheet 16 times to find one of those hidden settings??? Or more plausible: is there another (maybe two more) boards to be tested? Bad chip happens...

  • 0
    TI__Guru**** 244400 points
    Hello Anna

    Can you please share your code? Also you can check your code against the following code in the TI Design which uses a Macronix Serial Flash

    e2e.ti.com/.../505253

    Regards
    Amit
  • 0 in reply to Jane Doe
    Guru 27665 points

    Anna Maslyakova said:
    According to Spansion, the first 16 bytes of memory should contain a random number.

    Not quite, re-read the data sheet. Those bytes are in a different address space I believe.

    Robert

  • 0 in reply to Robert Adsett
    Prodigy 45 points

    Hi Robert,


    Thank you for your note. You are correct, 16 random number bytes are not at the 0x0 address.

    /Jane

  • 0 in reply to Bruno Saraiva
    Prodigy 45 points

    Hi Bruno,

    Your advice was very helpful. The actual problem was that the ratio between the CPU clock and SSI clock was not the power of 2.

    I really wish TI made the API less error-prone by taking a frequency divisor value instead of a separate frequency value.

    Thanks again,
    /Jane

  • 0 in reply to Jane Doe
    TI__Guru**** 244400 points
    Hello Anna,

    And what was the clock ratio? And what is the value you were programming and what was getting programmed?

    Regards
    Amit
  • 0
    Guru 117855 points

    Anna Maslyakova said:
    I am able to read the ID, read and change the state of status and control registers.

    As one here earlier exclaimed, "Not so fast!"    Holes in this story (nearly) as deep as Chicago's pot/sink-holes...

    Quoted above is poster's opening - she can (properly read & change) status & control registers.

    And then she cannot.

    And now she can.

    Really - could successful "read & change of status & control regs." be achieved w/major frequency violations?

    And it's the API's fault - never the poster's...

    I am not "unsympathetic" to our poster - yet the attack on the API seems ill chosen when contrasted w/the "misread of the memory's data sheet" & the initial report of  "read/write" success.   Fact & fiction (likely) intermingle herein...

  • 0 in reply to cb1_mobile
    TI__Guru**** 244400 points
    Hello cb1,

    And we have no evidence of API causing a frequency violation. if the poster can present the same, we would gladly acknowledge the same and fix it in accordance with expectation of the API.

    Regards
    Amit
  • 0 in reply to Amit Ashara
    Guru 47900 points

    Indeed Amit - indeed.    Far easier to, "Blame the cursed API than the man person in the mirror!"

    API (somehow) avoided mis-reading the memory chip's data-sheet - yet absorbs all blame...