K22 DSPI in Slave Mode Sometimes Has Duplicate TX Bytes

[chuckhorkin]

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?

[Hui_Ma]

Hi,

What's the MCUXpresso SDK software package version you are using?

Have you tried with the latest MCUXpresso SDK software package ?

The latest SDK Version for FRDM-K22F board:

KSDK 2.3.0  (released 2017-11-16) 

best regards,

Mike

[chuckhorkin]

We were using SDK 2.2.0.  We tried KSDK 2.3.0 and see the same issue.  Is it possible this is introduced by the FIFOs?  The next thing we can try is rewriting all the SPI driver to not use the FIFO....

[Hui_Ma]

Hi

Please provide the K22 product full part number and related mask set (You could find related info at chip surface silkprint). Thanks.

The FIFOs should not affect the SPI transmit.

Have a great day,
Mike

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

[chuckhorkin]

MK22FN512VLH12 

ON50M

CTAA1611B

[Hui_Ma]

Hi,

Thank you for the info.

Please try to call the DSPI_FlushFifo() function before the SPI Slave transmit?

Wish it helps.

Have a great day,
Mike

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

[chuckhorkin]

Hello,

We tried this but nothing changed.  No surprise here because the SPI Slave transmit function, DSPI_SlaveTransferNonBlocking(), already calls DSPI_FlushFifo().

[Hui_Ma]

Hi Chuck,

Please help to provide your DSPI slave code.

I want to regenerate your mentioned issue on site.

Thanks.

best regards,

Mike

[chuckhorkin]

Where can I attach it?  I have stripped down our code and have a reproducible build source I can give you.

[Hui_Ma]

Hi Chuck,

When you want to attach a file, please click [Use advanced editor], then you can find [Attach] button.

Thanks.

best regards,

Mike

[chuckhorkin]

Attached is an example which reproduces the issue.  The SPI slave (the device running this code) should send the bytes {1, 2, 3, 4} on ever transfer of 4 bytes.  Sometimes we get {1, 1, 3, 4}.

[chuckhorkin]

Were you able to duplicate the issue?  Any feedback?  Thanks.

[Hui_Ma]

Hi Chuck,

First of all, sorry for the delay reply.

I could regenerate your mentioned issue.

While, I find you are using K22 SPI1 module, not SPI0.

Please check below difference about K22 SPI0 vs. SPI1:

I also check the MCUXpresso V2.3 for FRDM-K22F board DSPI slave half-duplex-transfer demo, which is using SPI0 module with below register setting:

If you could change your application code with SPI0 module, then check if there still with the same issue?

Wish it helps.

Have a great day,
Mike

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

[chuckhorkin]

Hello,

We actually originally used the SPI0 before and had same issue. we have since changed to SPI1 for a different reason and the issue remains.

Also, just a note that we are configured for full dupleex.

Any other suggestions?

[Hui_Ma]

Hi Chunk,

First of all, sorry for the later reply.

Could you tried to use the DSPI interrupt mode to do the SPI slave communication?

Please refer the MCUXpresso SDK for K22 DSPI driver example <interrupt> for the detailed info.

Using this way, it will clear to see the communication process.

Wish it helps.

best regards,

Mike

[chuckhorkin]

Mike,

The example I gave you is already using DSPI_SlaveTransferNonBlocking() which uses the interrupts.  This is the same thing done in "interrupt transfer" example.  There is another example called "Interrupt" that doesn't use the SDK Interrupt Handlers but instead re-implements them.  Is that what you are asking me to try?  Is there a known issue with the SDK interrupt handlers?

[Hui_Ma]

Hi Chuck,

Yes, I want you to try with the [interrupt_b2b]_slave demo, which located at below default folder:

..\SDK_2.3.0_FRDM-K22F\boards\frdmk22f\driver_examples\dspi\interrupt_b2b\slave

Thank you for the attention.

best regards,

Mike

[cheekaitan]

Hi Mike,

I have some new findings after I use the example codes from KSDK2.3.0. I saw that if I were to toggle the SS line between bytes (as shown in the first image), the communication seemed to function without issue:

However, if I were to toggle the SS line between multiple-byte transfers (as shown in the second image), I would encounter the issue again:

Do you have any idea why I would see such behavior?

Thanks,

Chee

[Hui_Ma]

Hi Chee,

Sorry for the later reply.

I find the same issue from FRDM-K22F board.

With using the continue chip select, the first byte will be transfer twice.

The SPI chip select continuous asserted:

The SPI chip select is not continuous asserted:

The K22 reference manual shows below info:

The SPI Slave shift register will be updated with two conditions (Or logic):

1> at second SCK clock edge of the each frame to the shift register if the SS signal is asserted;(shift register old value will continue be transferred, after that start to transfer the new value)

2> any time when transmit data is ready and SS signal is negated.(shift register value will be updated with new value, and start to transfer the new value)

So, when the SPI Slave TX shift register will transfer the first byte twice with SS signal continuous asserted.

When SPI Slave with SS signal negated will load new value to update the TX shift register.

My test software is based on [dspi_interrupt] demo with below path:

..\SDK_2.3.0_FRDM-K22F\boards\frdmk22f\driver_examples\dspi\interrupt

Wish it helps.

Have a great day,
Mike

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

[wesleyxie]

Hi，Mike

I searched the DSPI in this forum, and found you answer about DSPI on K22.

I have a question about DSPI2 on MPC5746C, could you please help me to figure it out.

please follow this link for the details:

 could MPC5746C slave DSPI2 correct clock/bit skew error on next comming CS period  

thank you.

/WX

[cheekaitan]

Hi Mike,

Thanks for the detailed explanation. That's helpful, so it looks like this is an expected behavior. 

My next question would be: is there a way we can make this work with continuous slave select? Or it is just necessary to toggle the SS line between every byte transfer due to how the hardware is designed? 

Thanks,

Chee