DS1054Z not triggering on SPI CS/

[mbratch]

I have my 4 channels hooked up, in this order, to CS/ MISO MOSI and CLK on an active system using SPI bus.

I am able to trigger on the CS/ by using Edge triggering and falling edge and can see all the SPI signals I'm monitoring on this triggering.

However, the SPI triggering is very fussy. I had it working at one point, with the trigger set to SPI, the event to trigger on set to CS, the CS channel set to 1, and the mode set to "low enable" (from high to low to high again in the little icon). I also have the SDA channel set to channel 3 (my MOSI channel) and clock set to channel 4, and data set to XXXXXXXX (set to 8 bit data). I was making changes to try and trigger on specific data, which was not working for me for some reason. But it seems to have just stopped working even with data set to XXXXXXXX and nothing I do will get it to trigger again. Going back to Edge trigger, it triggers on channel 1 falling edge every time I expect it to. But the SPI triggering is being very stubborn. I think I've gone through all the settings and they seem correct.

I've checked that the trigger level in all of the channels, particularly, the CS/ (channel 1) is within proper range of the signal going from high to low.

Is there anything else I need to check for or be aware of that isn't mentioned in the manual?

[Martin72]

Hi,

In the past we´ve tried several times to use the spi trigger but didn´t get stable results.
Today we use the pulse trigger instead with defined timeout, trigger on the channel with the data-package.
Note: We use 2-ch spi, with clock and data only.

Martin

[mbratch]

Hi,

In the past we´ve tried several times to use the spi trigger but didn´t get stable results.
Today we use the pulse trigger instead with defined timeout, trigger on the channel with the data-package.
Note: We use 2-ch spi, with clock and data only.

Martin

Thank you, Martin. At least it seems it's not just me.

I have another hardware setup that uses SPI with a clock that's normally low but still rising edge to clock data. CS/ is still low for select, and I have just MOSI, no MISO. That setup seems to trigger reliably with the SPI trigger. But maybe I'm just lucky. It does seem though, in just about any case when I am doing I2C or SPI, I'd doing a lot of fussing with the scope, trying different triggers, until it finally triggers the way I want and it usually continues to work after that. Not in this case, though.

I can trigger on edge or pulse but, sadly, I will then lose a key benefit of SPI triggering, which is to trigger on a specific data value. I may keep playing with it to see if I can get it to work. I would suppose that since the DS1054Z has been out for several years now that Rigol is not interested in fixing such an issue.

[Martin72]

Apart from the question if this is a issue or we are just too dumb, Rigols fixing policy drived me so mad that I´ve changed to siglent nearly 2.5yrs ago.

[mbratch]

Apart from the question if this is a issue or we are just too dumb, Rigols fixing policy drived me so mad that I´ve changed to siglent nearly 2.5yrs ago.

I can totally understand that. Which Siglent model do you have? I just bought my Rigol a few months ago. I had done my research, I thought, but I had not encountered any comments from users having triggering issues for common serial bus protocols. I have wondered whether I should have instead gotten a Siglent sds1104X-U, but wasn't sure if I'd be just trading one set of issues for a different set. For doing some data-level analysis, I'm thinking about supplementing my Rigol with one of those $150 USB logic analyzers. I've been reading up on those lately and they seem pretty capable for my simple needs. I can still use the Rigol to do the analog signal analysis.

[Martin72]

Which Siglent model do you have?

After DS1054Z ( we already got several at work) and MSO5000, first I´ve got a siglent sds1104X-E, a sds2104X+ which is still the best you can get for the money and since appx 2 weeks a sds2104x hd...

[mbratch]

Well, I finally got the !@#$% to trigger with the SPI triggering. I started from scratch and recalibrated my probes (a couple were off by a very small amount), and also discovered (and this is I think the primary issue) that the snap-on lead clip for channel 1, which is my CS/ channel, was providing erratic signal to the scope. I fiddled with it, resnapping the clip on and making sure it was truly, firmly on, and tried again and got it to work. The probe clips are somewhat twitchy...

So great, now it triggers.

Now on to the SPI decoding, which is another major irritation. It is very persnickety. It seems to require that the falling edge of CS/ be visible on the display or it won't interpret the data at the clock pluses. In my cases, I have lots of 8-pulse clock clusters across a period of time much wider than can fit on a display and keep the initial falling edge of CS/ visible. Why on earth does it care about the falling edge being visible? I know the falling edge of CS/ is the configured trigger, but as long as CS/ is low it should decode the data.

[Fungus]

Now on to the SPI decoding, which is another major irritation. It is very persnickety. It seems to require that the falling edge of CS/ be visible on the display or it won't interpret the data at the clock pluses. In my cases, I have lots of 8-pulse clock clusters across a period of time much wider than can fit on a display and keep the initial falling edge of CS/ visible. Why on earth does it care about the falling edge being visible? I know the falling edge of CS/ is the configured trigger, but as long as CS/ is low it should decode the data.

It only decodes what's visible on screen. It should decode if you don't put the middle of a byte on the left edge of the screen.

[mbratch]

It only decodes what's visible on screen. It should decode if you don't put the middle of a byte on the left edge of the screen.

Yep, I'm aware of that. As I mentioned, I can have all the clock pulses and data for the bytes fully on the screen, but if the leading/falling edge of CS/ isn't on the screen, it won't decode.

I just stumbled upon this post. It seems to be the same problem.
https://www.eevblog.com/forum/testgear/rigol-ds1054z-spi-decoder-issue/

I did try the recommendation in that thread to use Timeout instead of trigger on CS, and I did start to see decodings, but they were often inaccurate, even zoomed in. Totally worthless.

Attached is a sequence of examples from an SPI trace. The one that shows no decoding at all is because the CS/ falling edge is off the screen. Some other decodes have odd behavior (blank boxes).

If the decoding only operates on the screen-converted data, then that's extremely limiting and marginally useful. This would result in what I'm seeing: it doesn't know how to sync a byte unless the CS/ start edge is on screen, and the byte codes displayed as decoded values will be somewhat erratic. I've had cases where all I have to do is horizontally adjust the image a little and one of the byte codes changes. Clearly the unit has the original data and knows what part of it is being displayed. It would seem they could use the original data as a clue. As it is right now, if I'm trying to look at SPI data for a serial flash, the decode is useless since there can be long stretches of data transfer while CS/ is held low.