Keep chip select asserted during multiple DSPI_DRV_MasterTransferBlocking calls?

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Keep chip select asserted during multiple DSPI_DRV_MasterTransferBlocking calls?

529 Views
rajbatra
Contributor IV

Communicating with some flash that requires the read/write command and data to under a single chip select.

 

Either controlling the CS myself, or allocating a chunk of memory where I concatenate the two buffers seem inelegant.

I'd like to just call DSPI_DRV_MasterTransferBlocking twice (perhaps a flag that says additional transactions coming). Any way to do this?

 

Or is there a better API command I should be using?

 

I'm on a K64F using latest KSDK & MQX.

Labels (1)
0 Kudos
2 Replies

335 Views
Jorge_Gonzalez
NXP Employee
NXP Employee

Hello Raj Batra:

The master driver configuration structure dspi_master_state_t has a field called isChipSelectContinuous. I guess this should work with only 1 call to DSP_DRV_MasterTransferBlocking, by concatenating buffers as you mentioned. Have you tried that option?

If that does not fit your requirement then you would need to modify the SPI Master driver and rebuild the KSDK platform library, or use the GPIO driver to control the Chip Select pin.

Regards!

Jorge Gonzalez

0 Kudos

335 Views
rajbatra
Contributor IV

Hi Jorge,

Yes, concatenating buffers will work but I'm not a fan of (1) allocating memory and (2) spending operations on copying chunks.

I could modify the master driver as you suggest, but again not a fan because as you guys provide updates to the SDK, I have to remember to go in and change your API.

So perhaps this can be seen as a feature request to support a last_transaction flag in the API.

As a side, I think this is a regression in the API as looking at old code (MQX 4.2 era), the spi_memory.c would call fflush(spifd) at the end of the multi-block transfer to deassert the Chip Select.  (But perhaps internally, the fwrites were allocating memory!)

-Raj

0 Kudos