SPI peripheral's MSTIDLE status flag

[houe]

From my testing it appears that the SPI modules's STAT:MSTIDLE flag does not assert (change to 1) until the slave select gets deasserted. The user manual does not indicate MSTIDLE has any interaction with the slave select pin logic. This is what the user manual says:

I originally asked a similar question about a year ago that was buried with many more details here: Explain the SPI peripheral's MSTIDLE flag for LPC84x. I wanted to ask this question again in a much simpler way. 

So can this behavior be confirmed as correct? Does the user guide documentation need to be updated? Should this be an errata? Does someone want to challenge my findings? Etc?

Thanks.

[houe]

Thanks for the quick response.

In the link I gave there is code (a function) that waits for the MSTIDLE to assert - that code doesn't work because it hangs. I do explain the code and the sequence of operation in some detail. That code example should work even without any peripheral device connected. If you want a complete example project I could probably provide one for the dev board (although it might take me a couple days). I'd basically add the initialization stuff to that code.

However, it would seem that to resolve this question we would want to follow the following steps:

1. First, determine if my understanding of the user manual documentation is correct or not. Without an agreed upon meaning of the documentation code doesn't mean much.

2. Second, if my understanding of the user guide is agreed upon then lets reproduce the issue (with a code example) to everyone's satisfaction.

3. ....

[jeremyzhou]

Hi michael boyko,

Thanks for your reply.
I'd like to highly recommend you to upload a complete code which can replicate the phenomenon, as I'll like to run the code with the LPC845 MAX board to replicate this phenomenon.
Looking forward to your reply.

Have a great day,
TIC

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

- We are following threads for 7 weeks after the last post, later replies are ignored
Please open a new thread and refer to the closed one, if you have a related question at a later point in time.
-------------------------------------------------------------------------------

[houe]

Before I upload a demo project that demonstrate my issue can you answer a question for me. Do you agree that what I am describing should not happen?

If I create said demo project and then you come back and say its operating as expected... that the documentation is just a bit unclear on this particular point. That would seem like a waste of our time in reproducing this.

[jeremyzhou]

Hi michael boyko,

Thanks for your reply.
Yes, I agree with you, in my opinion, the MSTIDLE bit behave doesn't fit as the expected.

Have a great day,
TIC

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

- We are following threads for 7 weeks after the last post, later replies are ignored
Please open a new thread and refer to the closed one, if you have a related question at a later point in time.
-------------------------------------------------------------------------------

[1234567890 · Accepted solution]

At least in fsl_spi.c in in SDK 2.5.0 for LPC845 you can see:

/* Note that: the MSTIDLE status is related to the EOT bit, if the EOT is not set, the MSTIDLE bit will never be set even though there is no data in the FIFO and no data will be shifted by the bus line. so, please don't check the MSTIDLE status if the EOT bit is not set.*/

This relationship is not reflected in the UM.

And how can I check the idle state of the peripheral when I control SSEL manually with a GPIO pin? TXRDY isn''t suitable for that.

By the way:

The first screenshot says that 'SSEL0 asserted' is the reset/default value because the reset value of the bit is 0.

'Asserted' here means 'active' as well?

[houe]

Thank you so much for this independent confirmation of this behavior I first observed over 1 year ago! The NXP SDK code itself confirms the behavior I have been wondering about for over 1 year! I have not forgotten (so busy) about my promise to provide an example project that demonstrates this behavior - however, with this independent source confirming what I have been complaining about I no longer see it necessary to create the demo project. The behavior is no longer in question. NXP's own SDK confirms it!

I would encourage NXP to update the documentation for this peripheral (across all micros) to make this more clear. Or if this is behavior is not intended then add it to the errata. So jeremyzhou this is hopefully an action item for you. Can you please forward this information to the appropriate people so that documentation can be improved.

For those wondering about a work around - I used the RXRDY flag bit to know when a particular transmission completed. In order to do this however you do need to make sure to set RXIGNORE to 0 for the transmitted data and then read the "dummy data" to clear the flag. I wish there was an cleaner way, but it does work.

[jeremyzhou]

Hi,

Thanks for your reply.
Q1) And how can I check the idle state of the peripheral when I control SSEL manually with a GPIO pin?
-- Under the case, I think the TXRDY bit is the best indicator.
Q2) 'Asserted' here means 'active' as well?
-- Yes.
Have a great day,
TIC

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

- We are following threads for 7 weeks after the last post, later replies are ignored
Please open a new thread and refer to the closed one, if you have a related question at a later point in time.
-------------------------------------------------------------------------------

[houe]

Ok, thanks. I will create the demo project. It might be a few days until I find the time to do it.

[jeremyzhou]

Hi michael boyko,

Thank you for your interest in NXP Semiconductor products and
for the opportunity to serve you.
Before answering the question, I was wondering if you can introduce the steps of replicating the phenomenon in details, as it will help me to figure it out.
Looking forward to your reply.

Have a great day,
TIC

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

- We are following threads for 7 weeks after the last post, later replies are ignored
Please open a new thread and refer to the closed one, if you have a related question at a later point in time.
-------------------------------------------------------------------------------