Products > Test Equipment

SDS 1202 X-E I2C triggering bug

<< < (3/7) > >>

Performa01:

--- Quote from: 17_29bis on January 22, 2018, 07:20:25 am ---Thanks for the screenshot. There are many factors which may affect the result i.e. why it worked for you and does not work for me. For example the version of the used firmware (mine is the latest), different hardware and such.
The I2C setup is pretty simple on this o-scope so I am 100% sure everything is done correctly during my test.

Looking at your screenshot I am curios what those "~A" characters at the of each data string means. I don't see them on my screenshots. But assuming that "A" stands for acknowledgement the situation is even more weird.

...

PS: I am not sure why I see on your screenshot the first record in the table with decoded data: your trigger is set up to trigger on writing bytes 0x89 & 0x9A to a slave with address 0x2. First record means reading from the slave with address 0x4 several bytes which have nothing to do with  0x89 & 0x9A.  Should the decoding start from the line 2  ?

--- End quote ---

My screenshot is from the latest (currently one and only) firmware V7.6.1.12 – this information doesn’t help much as the firmware for SDS1x04X-E has lots of additional features, hence version numbers are quite different to the SDS1202X-E. Nevertheless, the I2C decoder shouldn’t be very different for the latest firmware versions for both scopes.

The “~A” character at the end of the decoded data strings actually means No Acknowledge. However, the current I2C decoder has a known bug; it might misinterpret the last acknowledgement at the end of a longer message as “no acknowledge”. We haven’t seen this bug with single byte messages yet and your decoding looks as it should. The acknowledgement in your messages is indeed correctly recognized by the scope.

A serial trigger can only fire after analyzing the address (and first up to two data bytes, depending on the trigger type and settings) of a message, which in turn means it has to receive this part of the message first. So it comes as no surprise that the triggered message starts before the trigger point, hence gets a negative timestamp (timestamps in the list are always relative to the trigger position).

It depends on the trigger position how many messages you see before the trigger event. As you can see, I have set the trigger position rather far to the left of the screen (68ms delay) so that I get only one additional message before the triggered one.

Apart from all that, I have no idea why the data trigger appears to fail in your setup. Maybe there actually is a bug in the SDS1202X-E that has been corrected for the SDS1x04X-E already. I would check that for you, but can do that only at the weekend, as I have no access to my lab during the week.

17_29bis:

--- Quote from: Performa01 on January 23, 2018, 09:44:24 am ---Apart from all that, I have no idea why the data trigger appears to fail in your setup. Maybe there actually is a bug in the SDS1202X-E that has been corrected for the SDS1x04X-E already. I would check that for you, but can do that only at the weekend, as I have no access to my lab during the week.

--- End quote ---

I took a different couple of master/slave devices and to my surprise  I2C decoding and triggering on "7 bit Address&Data" works. The major difference is in the size of the payload - during the failed test  the length of the payload was 1 data byte, in the second test the length of the payload varied from 4 to X bytes. Sorry, if I am asking a dumb question but how does one scroll horizontally  to examine the long array of data bytes in the table of the decoded I2C data? I could not figure out that yet. So, later when I have time I will probably write a small program that will generate different number of data bytes in the I2C payload to see how its affects the triggering in "7 bit Address&Data" mode.

Triggering on 0x00 0xB1 data bytes (the  second data exchange):





--- Quote from: Performa01 on January 23, 2018, 09:44:24 am ---The “~A” character at the end of the decoded data strings actually means No Acknowledge. However, the current I2C decoder has a known bug; it might misinterpret the last acknowledgement at the end of a longer message as “no acknowledge”. We haven’t seen this bug with single byte messages yet and your decoding looks as it should. The acknowledgement in your messages is indeed correctly recognized by the scope.

--- End quote ---

Regarding acknowledge / no acknowledge. Triggering on  "no acknowledge" works just fine, I wrote a small program that scans I2C bus for addresses 0-127 to find all present devices and I could see  that o-scope would trigger right at the rising edge of SCL impulse for  "no acknowledge" signal on SDA line. So this is the good news. At the same time the decoder did no show any info (and I dod't know if this is by design) although in ideal world it could show the probed address and “~A” that you mentioned above.   

No acknowledge case:






--- Quote from: Performa01 on January 23, 2018, 09:44:24 am ---It depends on the trigger position how many messages

--- End quote ---

Thanks, I immediately figured that out after the serial trigger began to work. This is another screenshot showing the triggering on a different data byte and the relative time shift.
Triggering on  0x00 0xB0 data bytes (the  first data exchange):




Another moment that puzzles me a lot is the triggering on data length. So far I could not make it work - at all.



--- Quote from: Performa01 on January 23, 2018, 09:44:24 am ---My screenshot is from the latest (currently one and only) firmware V7.6.1.12 – this information doesn’t help much as the firmware for SDS1x04X-E has lots of additional features, hence version numbers are quite different to the SDS1202X-E.

--- End quote ---

That's really sad news, because I assumed that there was no much difference (other than the number of channels) between 1204X-E and 1202X-E. The 1202X-E was in stock and I ordered one. Knowing now that 1204X-E is more advanced I should have ordered it instead of 1202X-E.  As I can see 1204X-E has lower input capacitance (15 vs 18 pF). I am curious if it has 50 om input impedance , averaging triggering mode (1202X-E does not) and the missing capacitors issue....

17_29bis:
The last part.  First of all, there is a bug indeed. if the length of the payload is 1  byte then the i2C trigger on "7 Addr&Data" does not work as expected. Any attempt to set DATA1 or DATA2 to the value of  the payload will lead to the trigger failure. But if DATA1 is set to 0 then the trigger will be activated on _any_ 1 byte long payload, i.e it can be 0x80 or 0x81 - it does not matter because the value of  the payload itself is ignored.

Example1:


Zoomed version:




Example2:



Zoomed version:




It is important to note that in this case the trigger activates at the rise edge of the 9th clock after the first data byte (in this case the length of the payload is 1 byte)i.e  on the rise edge of ACK. I will show later how it changes depending on the way how the i2C trigger is set.


17_29bis:
Secondly. Looks like SDS1202X-E does not discard incomplete bytes in the payload although they are easily detectable. How do those incomplete data bytes occur? The data bytes may become incomplete due to too small capture time.

Example: 



There is no 0x00 byte at the end of the payload, the actual value is 0X0F as seen here:



Therefore if you see "~A" (which seems to mean "no acknowledge") at the end of the payload  make sure that your payload is not truncated (because the last byte may be wrong) or just increase the capture time. Not a big deal but still should be taken into account.

Performa01:
Well, looks like the I2C trigger/decoder has a few bugs, maybe even more than in the current SDS1004X-E firmware. I have already pointed Siglent to this thread so they can investigate and see if there’s anything new that they aren’t already aware of.

There are never dumb questions - only dumb answers…

And my dumb answer regarding the list view simply is that I don't know either. I can only speculate … maybe Siglent engineers thought that a few data bytes should be enough because I2C is mostly used for controlling peripherals where rather short messages are common.

Basically not a big issue though, as there would be an easy work-around utilizing the decoding line at the bottom of the screen. For this we'd need to zoom into the waveform so that the decoded data becomes readable. Then we can scroll through the entire message by changing the horizontal position.

There are two options:

1.   Just stop the acquisition by hitting the Run/stop Button. In Stop mode, you can set any timebase you want and use the horizontal position control to navigate through the entire record.
2.   While in Run, you can enter Zoom mode by pushing the horizontal time/div control. Once again, you can navigate by lowering the timebase and using the horizontal position control.

The SDS1000X-E will keep the decoder list for the entire record and automatically scroll the data that matches the signal trace into view. This allows you to examine the signal trace that belongs to a certain part of the message and also to see all the data bytes that are cut off in the list view. Currently this can be rather slow, especially with long records, so for the time being I generally recommend limiting the max. memory depth to 700kPts when serial decoding is used.

A device not answering doesn't generate any data either, this is probably why there also is no “No Acknowledge” notification. But I'll make sure Siglent reads this and maybe your suggestion will be picked up. I personally will support your request and cannot think of a reason why this should be hard to implement. So maybe this will make it into one of the future updates.

Data Length Trigger works with the length of Address and Data in bits. It is somewhat strange that the trigger fires on 10 bit data with my test stream – quite obviously there is some misinterpreting going on, at least when signals with certain timings are used. Apart from that, I cannot think of a useful application for this trigger in most standard scenarios. Since your messages are all the same, the scope will only trigger in this mode if you set the address to 7 bits and the data to 8 bits (or whatever number of bits has to be set because of the flawed interpretation) - but then, it will trigger on each and every message. This trigger obviously is only useful in a system with mixed message formats, where you want to trigger any messages that fit the format you've set for the decoder. Not sure how often this will see use in real applications - at least I for one have never seen let alone designed such a mixed format system on a single bus. This makes only sense for a multi-master system, which I've always tried to avoid at all costs.

Regarding the differences between SDS1202X-E and SDS1x04X-E you might want to have a look here:

https://www.eevblog.com/forum/testgear/siglent-sds1104x-e-in-depth-review/

But your specific questions are not explicitly answered there, so here is what I can tell:
A lower input capacitance is always nice of course, but 15pF vs. 18pF really doesn't make a noticeable difference in practical terms.

SDS1x04X-E scopes never had missing caps, because that problem was discovered before the first production units of this scope have left the factory.

The "E" in X-E stands for Economy. These are entry level scopes - albeit rather capable ones. But they don't feature an internal 50 ohm termination like the 1000X (without the “-E”) and 2000X do. In my review I have closely examined the input impedance of the SDS1104X-E with external termination.

Not sure what you mean by "averaging trigger mode". But whatever it is, the trigger system is the same for all SDS1000X-E models, except for the Ext and Ext/5 trigger sources, which are missing on the 4 channel models.

Navigation

[0] Message Index

[#] Next page

[*] Previous page

There was an error while thanking
Thanking...
Go to full version
Powered by SMFPacks Advanced Attachments Uploader Mod