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
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
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