K22 DSPI in Slave Mode Sometimes Has Duplicate TX Bytes

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

K22 DSPI in Slave Mode Sometimes Has Duplicate TX Bytes

11,588 Views
chuckhorkin
Contributor I

We're seeing an issue that only happens sometimes.  We are using the fsl_dspi.c/h modules with SPI in slave configuration.  We are transfering 4 bytes to the host and they should be: 0x79, 0xB8, 0xF8, 0x99.  However, sometimes, we actually get 0x79, 0x79, 0xB8, 0xF8.  Then, instead of getting an 0x99 on the next SPI transfer, we keep getting 0xF8.  It seems that there was some kind of error on the dspi_slave_transfer_callback_t(not kStatus_Success) and possibly an RX overflow.  We think we've tied this to SS behavior on the host side where the SS is held low longer, but we have no real explanation for why.

Has anyone had issues like this, or can point us in to how to proceed here?

Labels (1)
Tags (5)
0 Kudos
Reply
24 Replies

1,154 Views
Hui_Ma
NXP TechSupport
NXP TechSupport

Hi Chee,

If there need the continuous slave select, the SPI master need add 1 dummy byte read to update the SPI slave shift register.

For example, if SPI slave want to transmit 4 bytes, the SPI master need to do 5 bytes SPI communication. SPI master first received byte is a dummy byte.

Wish it helps.


Have a great day,
Mike

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

0 Kudos
Reply

1,154 Views
noperator
Contributor I

Hi Mike,

Thanks for explaining this strange behavior. I have a similar problem where my SPI slave needs to echo bytes back to the master without delay (see my comment on https://community.nxp.com/thread/391759 ). I cannot modify the master to do a dummy read or to use non-continuous SS. Is there really no other way to get around this issue from the slave side?

The only solutions that I see are:

1. Use 4-bit frames instead of 8-bit, that way the response is delayed by 2x4-bits instead of 2x8-bits. However, this makes the software a nightmare.

2. Temporarily set the clock to a different pin and clock in a dummy byte before the master tries to read. I'd like to avoid this as it would require hardware modifications on our boards.

Thanks,

Ivan

0 Kudos
Reply

1,154 Views
Hui_Ma
NXP TechSupport
NXP TechSupport

Hi Ivan,

Sorry for the later reply.

I don't find there with any difference for 4-bit frame vs. 8-bit frame.

In fact, when the SPI master want to communication with SPI slave. The SPI master need to provide the suitable communication signal and follow the SPI slave defined rule.

The SPI master will easy to change the communication process and drop the first received byte(dummy byte).

best regards,

Mike

0 Kudos
Reply

1,155 Views
cheekaitan
Contributor I

Hi Mike,

This is Chee. I have been working with Chuck on this issue. We have tried using the example in the interrupt_b2b slave demo. The issue still remains. Any other suggestions to workaround this? Thanks.

Chee

0 Kudos
Reply