Hello Mark_O.
Hi, Luis. Thanks for continuing to pursue this. I hope you don't interpret my comments as argumentative. I'm just trying to be helpful, and come to some understanding, along with you. I don't have a DS2000 here, or I'd hook it into one of my SPI-bus projects, and look for myself.
Some more info:
- As i can see, decode is not related to trigger at all but wave forms, you can even decode in auto triggering mode in the midle of a string.
Yes, but can you do so
properly? It's always possible to say, "
Start here and decode what you see", but getting the Start point correct is critical. Otherwise, what you get out is garbage.
- The lines i draw are in the correct place, confirmed with LA1034 LOGICPORT tool that is decoding as expected.
I'm sure they are correct, with the way you (and the LogicPort) are interpreting the stream. Does the Logicport have only two SPI lines connected, as the DS2000 does? Or does it also have a CE/CS (Enable/Select) line to help demarcate active segments?
One thing I noticed right away is that your last SPI snapshot actually has a gated CLK signal. In all the rest, it has been (or appeared) continuous. And with a continuous clock, no CE signal, and no gaps between data bytes (to trigger a resync), how would
any device (or person) be able to tell where the byte boundaries were? I've written software SPI decoders before, and I couldn't figure that one out. So I wasn't surprised that the DS2000 couldn't either.
- I dont know how the scope knows the start bit, anyway it is doing it in not zoomed strings any kind of trigger.
Bingo! I think that's the crux of the problem. Sure you can ignore the trigger type. And yes, the DS2000 will scrape the display memory and (try to) decode anything you throw at it. But the Start bit is fundamental. Look back at your RS232 capture. It jumps in and interprets what it sees, but flags every byte as defective. That's because you didn't use RS232 triggering, which would let it know it needed to detect Start and Stop bits, to demarcate a byte cell. Without that context, Start and Stop bits are just more data.
- In SPI i trigger with CS signal, sometimes with GPIO, edge or SPI trigger with same result in zoomed string.
I'm not quite sure what you're saying here. If you mean that you're using a Select line (CS) through the ExtTrigger input, marmad has already explained why that won't work. It should! I think we all agree it would be much better if it did. Trying to decode SPI without it is problematic at best. But it doesn't.
- In current string I can not trigger In RS232 mode because the scope suport up to 900Kb for trigger, the string is 2Mb.
Ah, OK. So you've exceeded the documented capability of the scope. I didn't think of that right away, because the fastest I've ever driven RS232 in any of my designs was about 1 Mbit/sec.
I don`t know if any parameter is wrong, but ... decoded data don´t match waveforms.
I think the later implies the former.
Unless the scope is completely broken, which hasn't been reported here. Maybe it's just because you're the only one who has dug into this.
I don't know.
marmad:
- Where in the manual you can find this? "protocol decoding should be teamed with the corresponding trigger".
I'll let marmad respond to this (if he likes), but it's been my opinion that enabling a decoder should also at least default to the corresponding trigger mode. And then let you override that, where needed or appropriate. But the DS2000 is not the only scope that gives you the flexibility to hang yourself in this way. On the scopes I've seen, defaulting to the matching trigger mode is the exception, not the rule. You're forced to redundantly set both, and I'd guess this is because they're independent options. I.e., not linked, as they should be.
- After heavy use of decode function, i can asure that it is not dependant of trigger mode. Please see the new image, trigger SPI.
I don't think we can reach that conclusion at this point. For example, in your last screen shot with SPI triggering (thanks for trying that), we see a gated CLK-signal line, for the first time. AND all the data bytes are decoded correctly! Also for the first time. However, there is a 1 division skew in the decoded green boxes that I don't understand (yet). But I am curious about it.