I bought a new Saleae Logic 8 logic analyzer a few weeks back and I’ve been trying to use it tonight to try and debug a module I’m building. However, after closer inspection of the data that gets interpreted it seems to me that either its SPI analyzer is screwy or I don’t fully understand how this data is to be read. I’m hoping someone will teach me a lesson because I fully expect the Saleae is working as designed.
The part that confuses me is the MOSI line. If we look at the first 4 bits of the first byte they appear as 1100. The waveform of first 4 bits of the second byte appears identical to the first except that it is interpreted as 1000. Also, if you look at the MISO line below it, you will see that the same time is high for half the time and yet it is also interpreted as 1000. I’m confused. Can anyone explain this?
I agree - it looks weird. Is your clock sense and triggering the same as is set in the code? I used the Salae to debug the SPI traffic to the Wiznet W5500, but had some similar issues until I got the right clock sense and triggering selected.
It looks to be sampling on the rising edge of the clock and in the second one were it is 1000 it would indicate that the timing it just on the edge and it sees this as a zero.
What you find with a logic analyser is that you need to set the sampling clock to much higher than the clock you are using. In your example, the clock edge should not coincide with the data but should be somewhere in the middle. To low a sampling time will cause this to happen.
Can you set a higher sampling frequency on the analyser?
The MISO is narrower because that will be dependent on the device and the MOSI is your processor so is likely to be wider or narrower as the case may be. I expect the first byte should be 1000000 and the second 10000100 if I assume the clock is slightly delayed after the data goes active. How does this correspond with the device datasheet?
Thanks for the input. The timing on my Saleae was set to 40 MS/s and my SPI is running at 1000 KHz. So, I don’t really expect that to be the problem. I just tried bumping it up to the maximum 50 MS/s and didn’t get any different results.
The timing diagrams from the datasheet are attached. One of the things I’m trying to learn through this exercise is how to correctly interpret it. For one, why on my capture does the MOSI go low before the enable does?
It looks like you have different clock phase on master and slave and have set the Saleae to match the slave. The data should switch on the non sampled clock edge. The MOSI line violates this, but if you switched clock phase on the Saleae, the MISO line would validate it. This would also explain why the communication seems unreliable.
Well, it looks like I actually did have the clock edge configured opposite of my code. It does match now but as Frogmore anticipated that didn’t really remove the question
I’ve changed to 16 bits but I can’t figure out how to remove the trigger on the clock. I’ve added a trigger to the CS but I don’t see that its changed anything.
Generally speaking the trigger on Saleae doesn’t really matter. It doesn’t do real logic analyzer triggering, but it makes up for it by having a very large memory. If you are looking for problem that are easy to repro, it work fine. If you were looking for an error that only occurs sometimes, it would be very tedious to find it, but the search isn’t too bad for protocol, so that might work.
Back to your question. It looks like your slave device is “funny”. In the diagram you posted, there is a time that data is valid before (tCD) the clock edge that will be used to read it and also a time for how long it will stay valid after (tDCH) the clock edge. One of these appears to be very short and problematic. I would zoom into the area (+ sign, or mouse wheel, does not work with touch) and see how much time after the clock edge the data stays valid.
Was the timing diagram from the part data sheet? What does it spec for those times?
Also, I would stick with 8 bit mode, since it appears that is what the device is using, 8-bits for address and 8-bits or more for data. That way the bytes will be displayed in an easier to read order. That’s what I do when looking at multi-byte transfers.
Also, show some transfers with the single bit changes, it makes it easier to see you have things set up correctly. It also helps to know what the data is supposed to be, so you can know if the analyzer got the right answer (and if not, possibly why).
I agree but what puzzles me is this is a MAX31865 part that isn’t exactly new. I’m testing it with a driver from Codeshare that apparently works with a different board.
@ ianlee74 - You are using the beta version (1.2.3?) of the software (at least it looks like it). I have only played with that version myself, so I an not 100% sure the SPI decoder is accurate, though it looked fine when I was using it. It might be worth installing the stable version and testing with that.
@ taylorza - Yea, that’s definitely worth checking out. I’ll do that next.
However, I decided to try the same module & code against a different MCU to see how things might look and now I’m definitely no closer to understanding. This capture is against a Hydra+. The previous was with a Cerberus.
According to the datasheet, the chip doesn’t care. It automatically determines which mode to use whenever the CS is activated. I believe I’ve tried it both ways and it made no difference.
I hooked up my Reaper to try with it. It actually shows an almost ideal capture where everything falls in line with the CS. The MISO timings see short/off by half a clock or something. I think I’ll stick with this board now and try and send some known data and try and narrow things down now. Unfortunately, since the SPI code is built-in on both ends I’m not really sure how to adjust these sort of things.
