SPI Triggering Issue on SDS1104x-e Scope

[mrprecision]

Hi,

I use a Siglent SDS 1104X-E Scope with the firmware 8.1.6.1.26. I use the SPI decode which works fine. I send two bytes of date in a message to an dac with the usage of chip select. I setup the trigger to SPI to catch the dataword 0xFFFF as you can see in the image.

No if I increase the "break" between the two bytes (time between cursors) from 350ns only a little bit, than the trigger is not catching the 0xFFFF dataword anymore. I don't change anything on the scope. I only delay the secound byte by firmware.

Is there any timeout? I don't use CLK Timeout in the scope. I use ~CS.

Why is the SPI trigger not working it the secound byte is delayed mor than 350ns?

Can anyone help me?

[tautech]

Your waveforms don't look right.....like ch1 is a clock not the data stream.

Here's a screenshot of SPI from Siglents STB3......no Decode trigger, just a falling edge trigger with enough holdoff to not trigger again within the same packet.

[mrprecision]

Hi,

I don't agree. On my scope image CH1 ist the SPI Clock, CH2 the SPI Data 0xFF, CH3 the ~CS. I use the SPI Trigger Function with (CLK, MOSI, ~CS, no CLK timeout) for the Dataword 0xFF. As you can see, after the secound byte the Scope triggers. Everything fine. Now I increase the delay a little bit betwenn the two bytes. The scope not tiggering any more.

Is there any timeout?

[tautech]

Hi,

I don't agree.

OK, let's work through this with what we know.

Your screenshot:

On my scope image CH1 ist the SPI Clock, CH2 the SPI Data 0xFF, CH3 the ~CS.

OK, my image:


Ch 1 = clock Ch 2 = MOSI
We see a clock for each data transmission and while I am no SPI expert I do wonder about the SPI implementation you have used. 
Is it wrong, I'm sorry I do not know....maybe an SPI guru can help.

I use the SPI Trigger Function with (CLK, MOSI, ~CS, no CLK timeout) for the Dataword 0xFF. As you can see, after the secound byte the Scope triggers. Everything fine. Now I increase the delay a little bit betwenn the two bytes. The scope not triggering any more.

If we look at your screenshot again, the trigger appears to be on the rising edge of Ch 1 when to get correct Decode timing it should be on the falling edge. Maybe go through and double check channel assignments and other decode settings.

Is there any timeout?

Timeout as in like trigger holdoff, no not in the Decode trigger suite.

[mrprecision]

If we look at your screenshot again, the trigger appears to be on the rising edge of Ch 1 when to get correct Decode timing it should be on the falling edge. Maybe go through and double check channel assignments and other decode settings.

My SPI Slave is running on the raising edge of the CLK, therefore the trigger appears corret. For me everything is fine. But why is it not working for longer delays between the two bytes.

Timeout as in like trigger holdoff, no not in the Decode trigger suite.

For the trigger I use the SPI decoder. The only settings are ~CS, MOSI, CLK. There is no trigger holdoff or any timeout. Why is the delay between the two bytes important?

[TomThomas2]

Hi,
You said you changed the time between the data a little. What does this mean in numbers?
Have you tried multiple different delays? What are the results?

Is there a dedicated use case why you changed the timing?

[mrprecision]

You said you changed the time between the data a little. What does this mean in numbers?
Have you tried multiple different delays? What are the results?

I changed only the time between the two data points a little. Maybe arrount 1-4 CLK clock cycles. If I increase the time between the data, the scope is not tiggering any more for this data. Only if I change the SPI trigger mode from ~CS to CLK timeout. Than it is working.

Is there a dedicated use case why you changed the timing?

The 8-bit controller transfers the data as two bytes. Therefor the break.

[mrprecision]

I just created two Images from the Scope. With the following settings:

CH1: CLK
CH2: Trigger signal (if SPI triggering is not used)
CH3: SPI Data
CH4: ~CS


Image "SPI_360ns_ok.png":

You can see the two bytes of the SPI transfer with a delay of 360ns between the two bytes. The data word is 0x8000 as you can see also from the SPI bus decoding. The SPI trigger is also setup to the data word 0x8000. After the scope the data word a trigger event occurs.


Image "SPI_480ns_failed.png":

You see the exactly same data only with a longer delay. In this case the delay is 480ns between the two bytes. The data word 0x8000 is decoded in the same way as before. The SPI trigger doesn't occur. So for this I have set up the trigger to my own external trigger signal on CH2. Why is in this case no SPI trigger event. Ony the delay between the two bytes increases a little bit.

[tautech]

Still following along...........

For any protocol with a clock I set the trigger to the first edge of the clock....yes I see your trigger (Ch2) leads the clock but I do not understand why. 
Try setting the scope to trigger on Ch1 falling edge.

[tautech]

Hmmm it is a bit confusing, see screenshot.

Trigger set to clock falling edge while Decode requires clock set to rising edge. 



My setup won't work without these ^ settings and yet edges are aligned. Hmmm.

[Performa01]

I just created two Images from the Scope. With the following settings:

CH1: CLK
CH2: Trigger signal (if SPI triggering is not used)
CH3: SPI Data
CH4: ~CS

Could you please provide the CSV data for the traces in the 2nd screenshot? Just make it a ZIP-file and attach it to your next posting.

Siglent R&D will then be able to analyze your data and hopefully find the cause for the trigger malfunction.

[mrprecision]

I have saved both cases as png an bin file for you.

[Performa01]

I have saved both cases as png an bin file for you.

Siglent R&D has analyzed your data and confirmed this is a bug. It will be solved with the next firmware release.

[Performa01]

Please update your scope to the latest 6.1.33 firmware. This should solve the issue.

https://www.siglenteu.com/service-and-support/firmware-software/digital-oscilloscopes/#sds1000x-e-series