SPI sequence to read external flash IDs?

[dougpaulsen]

I'm sure the answer to this question is (as they say) "intuitively obvious to even the most casual observer" - but here I am anyway:

I am trying to get, via SPI, the manufacturer, device, and JEDEC IDs out of an external flash chip, in this particular case with an LPC55S06 as master and an external Winbond flash and using MCUXpresso IDE.  To get this info, the master needs to write a single byte command to the flash chip then read back a sequence of bytes.

Looking through the spi_polling_b2b_transfer_master sample and perusing the fsl_spi.c and fsl_spi.h files, the only non-interrupt function candidate seems to be the function SPI_MasterTransferBlocking().  This function, from reading the code, seems to be designed to concurrently write a block of data and read a same size block response.  

Not quite what I had in mind.  Is there some trick here (or even some other SPI interface functions) that I am just not seeing?

Thanks,

doug

[dougpaulsen]

Well, the function name leads me to expect it to work on something else but SPI_MasterHalfDuplexTransferBlocking() allows me to at least read the three IDs in my external flash device.  Here I have to MOSI a command byte then MISO a quantity of bytes.  I'll have to check out plain ol' data reads and writes, but I'm cautiously optimistic SPI_MasterHalfDuplexTransferBlocking() will do the trick.  Still, if wiser persons than I (a low bar, for sure) wants to hoist warning flags in my direction, please shout out.

[Alice_Yang]

Hello,

Thanks for your sharing, I will report it to SDK driver team.

BR

Alice

[dougpaulsen]

Boy, I don't know.... 

Is one supposed to use the SPI_MasterHalfDuplexTransferBlocking() function to send a command byte(s) to an SPI device then read the response byte(s)?  From reading the code, it almost seems possible (although when someone says "half duplex" I am thinking a single by-directional data line rather than separate MOSI and MISO lines....  Function SPI_MasterHalfDuplexTransferBlocking() just makes a temporary spi_transfer_t structure to pass to two separate calls to the original SPI_MasterTransferBlocking() function, one with the rx buffer blanked and one with the tx buffer blanked.  Seems a bit cheesy, but otherwise still outputs to the FIFOWR register and inputs from the FIFORD register.  If you've configured your pins as full duplex, then I don't suppose the SPI_MasterHalfDuplexTransferBlocking() call would care.

What a pain!  This is not obvious (to me, at least).