Strange SPI behavior with a Microchip 25LC01

Question

I have one of those situations where I believe that I have crossed my t's and i's, but things still are not working out; however, I'm new to SPI. I have a Microchip 25LC01, in 6-pin package, that seems to need extra clocks to send out commands, which is contrary to the datasheet. The best example of this behavior that can be illustrated in the command where I read the status register, and the Figure from the data sheet shows the following waveform:

So, you clock in an eight bit instruction and then 8 clocks after that you should have received your response. What I see is what follows:

A note, the signals are indeed 3.3V, but my scope is set to 5V resolution, which is what the 5V note is under each channel label. So, I send the command to read the status register, which is 0000 x101 and I get nothing back. The rising edge of the clock sits nicely in the middle of the command. However, this is where it gets stranger from here. If I read the status register again, I get a response.

What is likely the proper response is occurring 8 cycles AFTER I would expect it.

With microsecond timings, I am well in the within the specification for the timing on the IC, so my question is: Does Microchip have some special state machine behavior that is known well enough that they do not document it?

Solution Apparently, the problem was from /CS being deasserted too quickly after the last clock edge fell. Adding just a bit more time to /CS after the last clock seems to solve the problem.

Answer 1

One thing I notice is that in the first trace, you start with the clock high. Note that the datasheet shows the clock being low at the time chip select goes low.

It's also strange that MISO goes thru three states in the first diagram. It should be floating at first, so should be driven by only whatever pullup or pulldown you have on the line. The intermediate level after 8 clocks is strange because it's not solidly high or low. But then MISO goes fully low after chip select is de-asserted.

This almost seems like there is something else driving MISO than just the selected device and a weak pullup or pulldown somewhere. Maybe some other device on the bus is accidentally tied to the same chip select, or is always selected for some reason.

Sometimes it's easier to debug strange SPI problems by driving the bus strictly from firmware. That way you can guarantee to be changing only one output at a time, with some minimum time between changes and when inputs are read. Once you get the correct response from the device, you can go back to the SPI hardware and compare how its different.