EEVblog Electronics Community Forum
Products => Test Equipment => Topic started by: eutectique on April 27, 2020, 05:10:28 pm
-
Hello,
I am trying to catch an SPI packet with specific data. The setup looks like in the picture. Packet size is 32 bits.
Setting data to 0x4110A401 (2nd packet MOSI) or 0x00030201 (2nd packet MISO) does nothing, no trigger. The only trigger point I managed to get is the first packet, and not even the edge of CS, but somewhere in the middle.
User Guide did not help much. What am I missing?
-
What firmware version?
Don't think it should matter but 100mV seems a bit low for trigger point, can try increasing. Maybe try ignoring CS?
-
When you trigger SPI on data, it will stop after the packet is identified, so not at the beginning, but at the end of the 32 bits. It is set to trigger on any data after 32-bits (data pattern is XX XX XX XX and not the value you want to trigger on)
-
The firmware is the latest 1.3.0.1.
Yes, 100mV is for CS, active low.
I tried to trigger on MISO (CH4, active high), set the threshold from 100mV to 3V and set the data pattern to 0x4110A401 or 0x00030201 -- nope, it never triggers. Picture attached.
Only XXXXXXXX triggers on the first packet.
-
I am confused... there is no threshold when you are triggering on data. Can you show the trigger setup menu?I guess there is a threshold... It looks like it is decoding correctly, so I assume threshold levels for decoding are correct. Can you try copying the decoding setup to trigger?
-
Trigger is set on SPI with CLK on CH1 HIGH to LOW edge... I think SPI clock in your case is LOW to HIGH
-
Attached. The colour in the trigger window (UR corner) suggests the channel and level.
The user guide does not mention the level. On the other hand, UG names SPI signals as SCL and SDA, so no trust here or expectation that the trigger will work the same way as in Tek MDO4k.
-
Trigger is set on SPI with CLK on CH1 HIGH to LOW edge... I think SPI clock in your case is LOW to HIGH
Setting rising edge does not trigger even with XXXXXXXX pattern.
-
It looks like it is decoding correctly, so I assume threshold levels for decoding are correct. Can you try copying the decoding setup to trigger?
Just did it. The same, not trigger. No, it is other way around -- copy trigger to decoder.
-
The trigger threshold at 200mV is too low, any ringing will cause false triggers. Trigger threshold is when the edge crosses such value. Leave it at around 2V for a 3.3V logic signal.
-
I'm copying this here because it's a proper place:
Make a note that your packets are 64 bits not 32bits.. So you need to setup SPI for 64bit word and make first 32bits a filter and set rest of the 32 bits to to the end to x (don't care). And when it triggers, trigger point will be at the end of the packet, because that is the moment in time trigger circuit had it's condition qualified.
And like TK rightly said, set all the trigger and decode thresholds at appropriate levels, around 1,6V, so you don't have problems with levels..
-
I'm copying this here because it's a proper place:
Make a note that your packets are 64 bits not 32bits.. So you need to setup SPI for 64bit word and make first 32bits a filter and set rest of the 32 bits to to the end to x (don't care). And when it triggers, trigger point will be at the end of the packet, because that is the moment in time trigger circuit had it's condition qualified.
And like TK rightly said, set all the trigger and decode thresholds at appropriate levels, around 1,6V, so you don't have problems with levels..
I was going to comment about the number of bits, but later I thought that CS does not determine the bits... in SPI you can set CS low and start transmitting an arbitrary number of bytes. In the pictures I can see there is no pause between the first group of 32 bits and the second group, but does SPI require any pause or delay between the packets? Shouldn't the scope decode it correctly as 8 8-bit packets or 1 64-bit packet?
-
I'm copying this here because it's a proper place:
Make a note that your packets are 64 bits not 32bits.. So you need to setup SPI for 64bit word and make first 32bits a filter and set rest of the 32 bits to to the end to x (don't care). And when it triggers, trigger point will be at the end of the packet, because that is the moment in time trigger circuit had it's condition qualified.
And like TK rightly said, set all the trigger and decode thresholds at appropriate levels, around 1,6V, so you don't have problems with levels..
I was going to comment about the number of bits, but later I thought that CS does not determine the bits...
CS does determine the bits in an SPI frame towards the receiver because CS defines the start and end of an SPI frame but I think you meant to write that. However it depends on how the decoding is implemented / configured whether the decoder looks for the CS signal or uses a time-out.
-
I'm copying this here because it's a proper place:
Make a note that your packets are 64 bits not 32bits.. So you need to setup SPI for 64bit word and make first 32bits a filter and set rest of the 32 bits to to the end to x (don't care). And when it triggers, trigger point will be at the end of the packet, because that is the moment in time trigger circuit had it's condition qualified.
And like TK rightly said, set all the trigger and decode thresholds at appropriate levels, around 1,6V, so you don't have problems with levels..
I was going to comment about the number of bits, but later I thought that CS does not determine the bits...
CS does determine the bits in an SPI frame towards the receiver because CS defines the start and end of an SPI frame but I think you meant to write that. However it depends on how the decoding is implemented / configured whether the decoder looks for the CS signal or uses a time-out.
If it is like you say, then OP's packets are 64-bits, not 32-bits. I commented about CS because I remember seeing Arduino SPI implementations where they set CS low and just kept transmitting and receiving. Maybe my memory failed me...
If CS determines the bits, then why scope decoders ask for the number of bits in a packet? Just for CS timeout and ignore it when you trigger or decode on ~CS or it is a bad implementation?
-
It is possible to send out multiple words (word=group of bits) in one SPI frame. The OP's data seems to consist of 2 words of 32 bits but you can just as easely say there are 8 bytes. If the receiving end of the SPI bus stays synchronised to the master and doesn't need some kind of latch signal then you can set CS low for eternity.
-
If clock is continuous, as it is, it is a 64 bit burst, in one piece, inside one /CS event.
In decoder you decide how you are going to decode, 8x8 or 2x32.
But in trigger , you need to define 64bit mask. Simple as that. If you care only for first 8 bits (first byte) you setup that mask and set rest of 48 bit to X (don't care).
-
If clock is continuous, as it is, it is a 64 bit burst, in one piece, inside one /CS event.
It doesn't has to be. The NXP microcontrollers I use have buffers in their SPI interfaces. I pump a few words in them which then get sent as one long burst.
In decoder you decide how you are going to decode, 8x8 or 2x32.
But in trigger , you need to define 64bit mask. Simple as that. If you care only for first 8 bits (first byte) you setup that mask and set rest of 48 bit to X (don't care).
Why would you? If you set the word size in the decoder to 8 bit then your mask is 8 bits in size.
-
in SPI you can set CS low and start transmitting an arbitrary number of bytes. In the pictures I can see there is no pause between the first group of 32 bits and the second group, but does SPI require any pause or delay between the packets?
No pause is necessary between bytes, it is not specified.
From the master side, the controller asserts CS, drives the clock the requested 8xNbytes times, shifts the data in and out in the process, and deasserts CS. In MCU I am using the number of bytes is limited to 255.
From the slave side, my device is expected to receive a number of 32-bit words, with minimum of 2. It does not care about pauses between clocks either.
-
If clock is continuous, as it is, it is a 64 bit burst, in one piece, inside one /CS event.
In decoder you decide how you are going to decode, 8x8 or 2x32.
Correct. There is setting in the decoder, Width. I set it to 32 and get the correctly decoded data.
But in trigger , you need to define 64bit mask. Simple as that. If you care only for first 8 bits (first byte) you setup that mask and set rest of 48 bit to X (don't care).
The same setting, only named DataBits (did I mention QA before?), is present in the trigger. It can be set to anything from 4 to 32. This setting should instruct the trigger how to chop the bit stream. If I want to trigger on the value XXX30201 of MISO, I don't care, or don't know, which 32-bit portion of bit stream contains it.
Then, I want to trigger on data on MOSI. But the trigger setting only shows MISO! So, presumably triggering on conditions "MOSI data" or "MOSI or MISO data" is not possible.
To add insult to injury, let's look at some of the SCPI commands related to SPI trigger:
:TRIGger:SPI:SCL <-- I2C?
:TRIGger:SPI:SDA <-- WTF IS THAT??
:TRIGger:SPI:DATA <-- This one is "integer in the range 0 to 232-1", according to programming guide. Just try to set it to something corresponding to XXX30201.
:TRIGger:SPI:MODE <-- If you think it's SPI mode 0,1,2 or 3, you are wrong. It determines the active level of CS. The clock phase is nowhere mentioned in any SPI settings.
-
If clock is continuous, as it is, it is a 64 bit burst, in one piece, inside one /CS event.
It doesn't has to be. The NXP microcontrollers I use have buffers in their SPI interfaces. I pump a few words in them which then get sent as one long burst.
In decoder you decide how you are going to decode, 8x8 or 2x32.
But in trigger , you need to define 64bit mask. Simple as that. If you care only for first 8 bits (first byte) you setup that mask and set rest of 48 bit to X (don't care).
Why would you? If you set the word size in the decoder to 8 bit then your mask is 8 bits in size.
I don't care what is possible. I'm referring to scope capture in his firs post. There is clearly single 64 bit burst.
Decode byte grouping is separate from trigger mask...
-
If clock is continuous, as it is, it is a 64 bit burst, in one piece, inside one /CS event.
In decoder you decide how you are going to decode, 8x8 or 2x32.
Correct. There is setting in the decoder, Width. I set it to 32 and get the correctly decoded data.
But in trigger , you need to define 64bit mask. Simple as that. If you care only for first 8 bits (first byte) you setup that mask and set rest of 48 bit to X (don't care).
The same setting, only named DataBits (did I mention QA before?), is present in the trigger. It can be set to anything from 4 to 32. This setting should instruct the trigger how to chop the bit stream. If I want to trigger on the value XXX30201 of MISO, I don't care, or don't know, which 32-bit portion of bit stream contains it.
Then, I want to trigger on data on MOSI. But the trigger setting only shows MISO! So, presumably triggering on conditions "MOSI data" or "MOSI or MISO data" is not possible.
To add insult to injury, let's look at some of the SCPI commands related to SPI trigger:
:TRIGger:SPI:SCL <-- I2C?
:TRIGger:SPI:SDA <-- WTF IS THAT??
:TRIGger:SPI:DATA <-- This one is "integer in the range 0 to 232-1", according to programming guide. Just try to set it to something corresponding to XXX30201.
:TRIGger:SPI:MODE <-- If you think it's SPI mode 0,1,2 or 3, you are wrong. It determines the active level of CS. The clock phase is nowhere mentioned in any SPI settings.
It used to have SCL and SDA on the SPI decode as well, and I complained in the forum that SPI signal names are CLK, MISO, MOSI and CS, not SCL and SDA. Rigol changed some names in the last firmware update, but it looks like they did not care to check if decoder and trigger names match... |O