Need help triggering on SPI protocol Trigger Value

[PaulW]

Hello,  I am having difficulty using the SPI Trigger Value feature.  I have one SPI interface running at 8MHz.  I am using a Digital Discovery (but also have an Analog Discovery 2 that behaves the same way.)  I have connected my SPI channel to the Digital Discovery and then use a Normal Trigger, SPI Protocol, START condition, which works fine.  I can also trigger on the STOP condition and it works fine.  But when I choose Value and select the value I want, the device does not trigger.  I know that the value is in the SPI data stream because when I trigger on START, STOP or just simple clock triggers, I always see the 32-bit value I am trying to trigger on.  It seems that my SPI protocol trigger Value feature is not working.

I have tried using Waveforms in both modes (normal and NO LIMITS) and cannot get it to work.  I  have included snapshots of my Waveforms GUI with some more explanation of the problem.  Appreciate any help you can give me.

[PaulW]

10 minutes ago, PaulW said:

More information:  Checking or unchecking Clock Noise box does not seem to have any effect.

I am running WaveForms Version 3.8.2 64-bit Qt5.6.3 Windows 10

 

[attila]

Hi @PaulW

It is working for me with AD2 and with DD too, at up to 25MHz

Make sure to have ground connection between the AD2/DD and the analyzed circuit, use short wires, use the twisted wires with GND, or DD high speed adapter if you have.
Try to perform a highest sample rate capture (100/800MHz), to see possible cross talks, glitches...

The following can't be interpreted due to cross talk:

[PaulW]

Attila,

I am capturing the data just fine when using a SPI protocol trigger = START or STOP event.  So the ability to capture the data patterns is working.  The device does not seem to trigger on a specific 32-bit value after deserialization.  Any other ideas or things to try?

[PaulW]

I still can't trigger on a specific value when using the DD at 800MHz.  I have 3 Ground connections between the DD and the prototype board I am working with.

[PaulW]

I also notice that when I try to enter a Value in the SPI Trigger menu, there are several selections to choose from - or I can type in my own value.  I do not recognize the patterns that are available to choose from, where do these come from?  I did not enter these specific values.  Is this a clue to the problem?  See picture included.

 

[PaulW]

It is also unexplained why entering a SPI value = h00000000 causes the trigger to occur mutliple times, but it is not triggering on h00000000, it is triggering on any random pattern, usually the first full 32-bit pattern that comes available.

I have also tried using the advanced GUI but it does not seem to help.  It works for triggering on START and STOP conditions, but has the same behavior when trying to trigger on a VALUE.

[PaulW]

I tried using Waveforms on a Windows7 machine and got the same behavior.

[PaulW]

I downloaded the latest Waveforms, Version 3.9.1 64-bit Qt5.6.3 Windows 10 and the behavior got better.  I can now reliably trigger on hFFFFFFFF (see picture), but still cannot trigger on other patterns like h18A218A2 which I know is in the data - because I capture random data by triggering on a START condition and the pattern h18A218A2 is almost always appears. 

Using Waveforms (NO LIMITS) and using the Advanced triggering seems to do no good.

Could the digital trigger logic be getting confused because I do not terminate each SPI transfer with a rising edge on Select?

 

I found the problem - I can now trigger on my desired pattern of h18A218A2 but I have to enter in that digital pattern right-shifted by 1 bit ==> h0C510C51.  When I enter this value into the SPI protocol trigger - I am triggering as I desire - I see the pattern of h18A218A2 in my waveforms (despite that I am triggering on h0C510C51.)  

Any ideas as to why this is?  Why is the trigger pattern requiring a shift by 1 bit?

[PaulW]

Shifting the 32-bit value right by 1 bit works for every pattern that I am trying.  Well at least I can now use this to do my troubleshooting, I sure would like to know why I have to shift my desired trigger value by one bit.  Thanks for the help.

[attila]

Hi @PaulW

I see know what the problem is. For SPI mode 3 the trigger detector considers the high state of the clock after slave select activation as a clock pulse.
I added here high state condition with minimum pulse length, in order to have glitch filter, but have not thought about mode 3...
To trigger correctly, without bit shift, in the advanced menu change the event from high state to rising edge.

[PaulW]

Great, thank you!