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

3,571 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
24 Replies

2,302 Views
Hui_Ma
NXP TechSupport
NXP TechSupport

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

0 Kudos

2,302 Views
chuckhorkin
Contributor I

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

0 Kudos

2,305 Views
Hui_Ma
NXP TechSupport
NXP TechSupport

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

0 Kudos

2,301 Views
chuckhorkin
Contributor I

MK22FN512VLH12 

ON50M

CTAA1611B

0 Kudos

2,301 Views
Hui_Ma
NXP TechSupport
NXP TechSupport

Hi,

Thank you for the info.

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

pastedImage_1.png

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

2,301 Views
chuckhorkin
Contributor I

Hello,

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

0 Kudos

2,301 Views
Hui_Ma
NXP TechSupport
NXP TechSupport

Hi Chuck,

Please help to provide your DSPI slave code.

I want to regenerate your mentioned issue on site.

Thanks.

best regards,

Mike

0 Kudos

2,301 Views
chuckhorkin
Contributor I

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

0 Kudos

2,307 Views
Hui_Ma
NXP TechSupport
NXP TechSupport

Hi Chuck,

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

pastedImage_1.png

pastedImage_1.png

Thanks.

best regards,

Mike

0 Kudos

2,307 Views
chuckhorkin
Contributor I

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

0 Kudos

2,307 Views
chuckhorkin
Contributor I

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

0 Kudos

2,307 Views
Hui_Ma
NXP TechSupport
NXP TechSupport

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:

pastedImage_1.png

pastedImage_2.png

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:

pastedImage_3.png

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

0 Kudos

2,307 Views
chuckhorkin
Contributor I

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?

0 Kudos

2,307 Views
Hui_Ma
NXP TechSupport
NXP TechSupport

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

0 Kudos

2,303 Views
chuckhorkin
Contributor I

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?

0 Kudos

2,303 Views
Hui_Ma
NXP TechSupport
NXP TechSupport

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

0 Kudos

2,301 Views
cheekaitan
Contributor I

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:

pastedImage_1.png

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:

pastedImage_2.png

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

Thanks,

Chee

0 Kudos

2,301 Views
Hui_Ma
NXP TechSupport
NXP TechSupport

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:

pastedImage_1.png

The SPI chip select is not continuous asserted:

pastedImage_2.png

The K22 reference manual shows below info:

pastedImage_3.png

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.

pastedImage_4.png

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

pastedImage_5.png

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

2,301 Views
wesleyxie
Contributor III

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

0 Kudos

2,301 Views
cheekaitan
Contributor I

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

0 Kudos