K22 PE based SPI Slave TX FIFO Question

[richardchelmins]

Hey Community,

So I wrote a fairly straight forward Transparent spi layer between a host (master) and a ADC (slave), utilizing processor expert and the latest SDK. The board I'm using is the FRDM-K22F. From the perspective of receiving a message from the host, sending it to the adc, and then receiving from the adc, I've had no issue.

The problem comes in when I'm attempting to send that information back to the host. The host is expecting 2 bytes, and I use the command DSPI_DRV_SlaveTransfer, with the correct instance, a non empty TX Buffer, a non null RX Buffer, a length of 2, and a timeout period that is more than generous. Through debugging I've validated this information.

Yet, every single time I only send 0x00 and then the first byte I have in the TX Buffer.

An example would be

- Host sends 0x0C 0x00

- K22 receives this, and then sends 0x0C 0x00 to the ADC

- ADC sends back 0x7F 0xEA

- K22 receives this, and then sends 0x00 0x7F to the Host

Any help would be very welcomed.

Regards,

Richard

[Jorge_Gonzalez]

Hello Richard Chelminski:

Can you share your project so I can give it a check?

It's hard to see the problem only by your description.

Regards!

Jorge Gonzalez

[richardchelmins]

The setup code was done using ProcessorExpert with the following configuration

Slave: SPI1, 2Mhz Clk, 8 bits per frame, Active Low Clk, MSB First

Master: SPI0, 2Mhz Clk, 8 bits per frame, Active Low Clk, MSB First

A simplified version of the code (taking out case statements and other logic) is the following

uint8_t * MasterRxBuf[2];

uint8_t * MasterTxBuf[2];

uint8_t * SlaveRxBuf[2];

uint8_t * SlaveTxBuf[2];

void fooTask( task_param_t param)

{

     DSPI_DRV_SlaveTransferBlocking(dspiSlave_IDX, NULL, SlaveRxBuf, 2, 10);

     memcpy(MasterTxBuff, SlaveRxBuf, 2);

     DSPI_DRV_MasterTransferBlocking(dspiMaster_IDX, MasterTxBuff, NULL, 2, 10);

     DSPI_DRV_MasterTransferBlocking(dspiMaster_IDX, NULL, MasterRxBuff, 2, 10);

     memcpy(SlaveTxBuff, MasterRxBuf, 2);

     DSPI_DRV_SlaveTransferBlocking(dspiSlave_IDX, SlaveRxBuf, SlaveTxBuf, 2 , 10);

}

All of this works fine up until that final Slave TX, where it puts a 0x00 and then the first byte of the real data.

See below a Saleae capture of this occurrence. 0x2C00 was received, 0x2C00 was sent out, and then 0x052C was received and only 0x0005 was sent out