• State TI Thinks Resolved
  • Locked Locked
  • Replies 6 replies
  • Answers 1 answer
  • Subscribers 31 subscribers
  • Views 455 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.

Original question:

Compiler/TM4C1294NCPDT: spi external flash code sample

Compiler/TM4C1294NCPDT: Read spi flash mmem reading its id>

Sergey uskach
Intellectual 690 points
Part Number: TM4C1294NCPDT

Tool/software: TI C/C++ Compiler

hi

According to manufactorer of spi flash

Read Manufacturer / Device ID (90h)
 The instruction is initiated by driving the /CS pin low and shifting the instruction code “90h” followed by a 24-bit address (A23-A0) of 000000h. After which, the Manufacturer ID for Winbond (EFh) and the Device ID are shifted out on the falling edge of CLK with most significant bit (MSB) first as shown in Figure 39. The Device ID values for the W25Q64JV are listed in Manufacturer and Device Identification table. The instruction is completed by driving /CS high.

Basically how I can execute this sequence  using SPI_transfer(*spihandle, &masterTransaction)

I do transaction count = 4

First byte of  write_buffer[0] = 0x90;

My read_buffer and write buffer is 64 bytes and all initaized as 0.

According to flash manufacture I should get back 2 bytes.

How I can write 4 bytes but read only 2?

According to manufacture spec I should get 1st bytes 0xEF ,

If I d just SPI_transfer for 4 bytes  count and {0x90,0,0,0,0 };

what is coming back is all 0.

If I am tring to do second spi_trancefer  for expected 2 bytes  my system crashes in second spi transfer

How I can execute this command on spi bus using spi transfer api call.
thanks.

  • 0
    TI__Guru 72500 points

    The short answer is that you do an SPI transfer of 6 bytes. What you transfer is 0x90, 0x00, 0x00, 0x00 dummy, dummy. (dummy is anything, you don't care.) What you have in the receive buffer after the transfer is dummy, dummy, dummy, dummy, 0xEF, 0x16. Your software needs to know that the real data will be the 5th and 6th bytes in the receive buffer. I suggest you look at the SSI pins with a logic analyzer or digital scope to verify you have the correct format and chip select timing.

  • 0 in reply to Bob Crosby
    Guru 117855 points

    Greetings,

    Use of a scope or logic analyzer IS strongly recommended.     That said - the requirement for '24 address bits of 0' complicates your 'scope/l.a.' read.    (i.e. as there are no discernible data bits to observe!)

    To enhance the 'success & ease' of your scope capture - it is suggested that you [initially - only for SPI Data Test Purposes] (temporarily) replace '0x00 w/the (instantly recognizable) '0xAA or 0x55' - which toggle each data bit w/the SPI clock.    Indeed - this will not recover your device ID - yet  'Importantly DOES insure that your data is (both) present & properly presented!'     

    Once satisfied that your SPI format 'is correct' - you can then present the specified, '0x90, 0x00, 0x00, 0x00, dummy, dummy.'   (6 bytes)    Insure that those bytes chosen as 'dummy' do not overlap 'any/all' SPI flash commands or critical values - again our firm's preference is to 'Not employ 0x00' as it proves (too often) 'unrecognizable!'    (as it is far too common occurring!)   

    Seeding your MCU buffers w/'0x00' may also warrant 're-consideration.'     Replacement w/a 'more inspired/recognizable unique value' (or values) - often 'far better proves/confirms a successful (MCU initial & then flash device write) - both very, 'Much to your advantage...'

  • 0 in reply to Bob Crosby
    Intellectual 690 points

    Hi Bob:

    Thanks for reply,

    Here what I did :

    I filled received buffer with 0xff;

    I did wrote 6 bytes  and my first byte was 0x90 with the rest 0;

    After executing spi_transfer my receive buffer first 6 bytes are 0 the rest is 0xff.

    Are any other options for me except connecting the scope to see what is going on ?

    I do nt have for now pins location on PCB to hook up a scope.

    Thanks

  • 0 in reply to Sergey uskach
    Guru 117855 points

    Sergey uskach said:
    Are any other options for me except connecting the scope to see what is going on ?

    It is likely that your management (alignment) of the memory chip's 'CS' and the MCU's 'FSS' signal proved incorrect.     The MCU's 'FSS' output can be replaced via a (different) GPIO Pin Control - enabling the MCU to 'perfectly' match the memory chip's 'CS' requirement...    (You must carefully note if the memory device 'requires' that its 'CS' pin be held at a constant level - throughout the ENTIRE 6 byte SPI transaction.)

  • 0 in reply to cb1_mobile
    Intellectual 690 points

    Hi Bob:

    CS I was able to verify with scope it is correct.

    What else I can try without scope?

    Sergey

  • 0 in reply to Sergey uskach
    TI__Guru 72500 points

    Without a scope you can review the that the data format you programmed is correct for the EEPROM you chose. Other than that you really need to look at all four signals, SSICLK, SSITX, SSIRX and SSIFss. If SSICLK, SSITX and SSIFss are correct, but you see nothing on SSIRX, then the problem is on the side of the EEPROM, not the TM4C. 

    If you cannot get easy scope pictures from your custom board, you can try running your code on an EK-TM4C129XL lauchpad if you have one. Of course you will not get a proper response when not connected to the EEPROM, but you should be able to get scope or logic analyzer pictures to compare to the EEPROM specification.