Rigol MSO5074 Logic Analyzer issues

[jerryk]

I'm trying to debug an initializer function for an I2C library that I want to work with an LCD and a pic microcontroller.  I figured the MSO5074 would be quite capable as I have used it previously for the exact same thing but via serial communication.

Attached are some images at various resolutions of my problem.  Basically the decode trace decoded data disappears when I zoom past 20ms making the LA function on this scope useless.  I must or hope I'm doing something wrong.  Any ideas what I'm missing here?

On the paranoid end of things I did the upgrade hack recently and hoping that did not cause a foul.

Jerry

 

[thm_w]

For this sort of task you are better off with a $10 USB logic analyzer and sigrok.
You are writing the code on the PC, why not use the PC to also look at the I2C data.

https://www.eevblog.com/forum/testgear/saleae-logic-pro-16-vs-rigol-mso5000-series/

Its not related to the hack.

[jerryk]

Thanks. I appreciate and will consider your suggestion.   However,  I'm just wanting to use what I have at this moment and I'm in disbelief that this is really all the decode capability of the MSO5074 of an I2C signal.  Without being able to zoom in on individual packets I'm left to manually decode the majority of the signal.  Something seem faulty and I'm sure it's on my end.  Otherwise, the LA on the MSO5074 is useless for my purpose.  Still hoping for an answer.

Jerry

[tggzzz]

General principle: use an analogue domain tool (scope) to assess analogue properties (signal integrity and timing). Once SI is assured, flip to the digital domain and use digital domain tools (LA, protocol analyser, printf() ).

I have heard that low-end Rigol scope only analyse what's visible on the screen, not what's in their entire capture buffer. If that is the case, yes, they do become less than useful. Important caveat: I do not have any Rigol equipment, so those statements are worth what you paid for them. Check with more knowledgeable people.

[2N3055]

General principle: use an analogue domain tool (scope) to assess analogue properties (signal integrity and timing). Once SI is assured, flip to the digital domain and use digital domain tools (LA, protocol analyser, printf() ).

I have heard that low-end Rigol scope only analyse what's visible on the screen, not what's in their entire capture buffer. If that is the case, yes, they do become less than useful. Important caveat: I do not have any Rigol equipment, so those statements are worth what you paid for them. Check with more knowledgeable people.

If you read again, his problem is that scope stops decoding after time base is slower that certain value. His data IS on screen.Screen IS entire capture buffer.

EDIT: Sorry..  Thanks @NE666!

[NE666]

scope stops decoding after time base is slower that certain value. His data IS on screen.Screen IS entire capture buffer.

It's the other way around isn't it, looking at the images? It's at the faster (i.e. shorter capture) timebase where decoding fails, since it doesn't then have a full data frame (in the screen display buffer) to to work with.

[2N3055]

scope stops decoding after time base is slower that certain value. His data IS on screen.Screen IS entire capture buffer.

It's the other way around isn't it, looking at the images? It's at the faster (i.e. shorter capture) timebase where decoding fails, since it doesn't then have a full data frame (in the screen display buffer) to to work with.

Yes you are correct!

Sorry for mistake. Not enough coffee this morning. Sorry @tggzzz !

[tggzzz]

scope stops decoding after time base is slower that certain value. His data IS on screen.Screen IS entire capture buffer.

It's the other way around isn't it, looking at the images? It's at the faster (i.e. shorter capture) timebase where decoding fails, since it doesn't then have a full data frame (in the screen display buffer) to to work with.

Yes you are correct!

Sorry for mistake. Not enough coffee this morning. Sorry @tggzzz !

No problems We all make mistakes

Useful to see my dim memory of the point is both correct and relevant.

[electr_peter]

Some Rigol scopes do not read digital input channels at slow time bases Rigol DHO900 logic analyser can only do fast
Maybe related.

[NE666]

My question is, what are you actually trying to accomplish? If it is to more closely examine the analogue signal properties on either the data or clock line, at a particular message field, then could you not use the horizontal zoom for that?  My LA decode still overlays the appropriate values on the second timebase.

[jerryk]

I'm trying to trouble shoot a startup sequence for an I2C LCD display.  I have two libraries that I'm trying.  One works and the other does not.  I wanted to contrast the two startup sequences using the LA as a debug tool.
My assumption is to set the scope on single event trigger and set a time base that will capture the entire startup sequence. Then examine the decoded I2C streams data.  I see no other way than to zoom in.  I'm new to this and may be going about it wrong.  I'm not trying to blame the scope.
 
Setting that aside I was just wanting to learn how to use the LA on my scope and this project seemed like the time to get familiar with the LA function.

Jerry

[Fungus]

I'm trying to trouble shoot a startup sequence for an I2C LCD display.  I have two libraries that I'm trying.  One works and the other does not.  I wanted to contrast the two startup sequences using the LA as a debug tool.

Usually it's much easier to compare the source code...

Or hack the library to print all the data it sends over i2c on the serial console in HEX format.

My assumption is to set the scope on single event trigger and set a time base that will capture the entire startup sequence. Then examine the decoded I2C streams data.  I see no other way than to zoom in.  I'm new to this and may be going about it wrong.  I'm not trying to blame the scope.

Decoders have "event tables" that show all packets as a list.

[tggzzz]

I'm trying to trouble shoot a startup sequence for an I2C LCD display.  I have two libraries that I'm trying.  One works and the other does not.  I wanted to contrast the two startup sequences using the LA as a debug tool.
My assumption is to set the scope on single event trigger and set a time base that will capture the entire startup sequence. Then examine the decoded I2C streams data.  I see no other way than to zoom in.  I'm new to this and may be going about it wrong.  I'm not trying to blame the scope.
 
Setting that aside I was just wanting to learn how to use the LA on my scope and this project seemed like the time to get familiar with the LA function.

Jerry

Sounds like a job for a BusPirate5, or similar.

It also sounds like a good way of "tapping the wheels" (railway wagons) or "kicking the tyres" (cars) before taking the new toyl out for a journey

[NE666]

Sounds like a job for a BusPirate5, or similar.

I have to agree. I understand the OP's desire to use and learn the tool they have rather than further investment and I think it's possible to do so, using combinations of the methods/features described above. However, a totally different question is "is this the fastest, easiest and/or most efficient and comfortable way to do this" and there I'd have to say no.

For comparing the content of long sequences of message exchanges and being able to search such content flexibly, the UI of PC-attached tools is far better suited, imho and experience. If it were me, I'd be investing 10USD or so in one of the myriad "Saleae LA clones" and using that in conjunction with the openly available Sigrok Pulseview software for this particular task.

[jerryk]

Every time I visit this forum I learn something.  Every other visit I seem to spend some money. So I have a cheep clone LA on the way and maybe that will help me reconcile the problems I'm having using Rigols LA.

As for my ability to use this Rigol for decoding I currently have the string "Press key" in a while(1) loop being displayed on the LCD.  I cannot find that string or most of it's characters using LA.  I have tried the event table, zoomed in on the data stream and manually decoded each data byte, and used the trigger function to the best of my ability and can't even to a single trigger on the first letter in the string"P" hex 0x50.

I'm sure I need to be taken out the wood shed and whacked a few times on the head so feel free.  I just want to learn.  One other point to notice is the LA settings in the Acquisition menu are greyed out.  Maybe a feature in higher end models?.

I'm sure the clone LA and Sigrok are going to help me learn and formulate a better understanding of my failing with this scope's LA.  I wasn't sure if the BusPirate5 was a serious suggestion but will look at it too.

As always - Thanks for the help.

Jerry

[Fungus]

Shouldn't SCL be HIGH between packets? 

[jerryk]

Well that nudge helps.  I still cannot figure out why it is being pulled low between packets.  Keep in mind this is the LCD library that works and displays character strings without any visible issues. Since both SCL and SDA are both pulled high with 4.7K resistors I assume it's in the library code itself.

Here is a picture of the other nonworking LCD library's I2C data and the decoder seems to be working fine with it.  It hangs in the init sequence still but I'm making progress.

I have a good direction to head now.

Thanks - Jerry

[Howardlong]

You can reliably use I2C decode on the LA on this scope, but there are some limitations. There are fewer limitations when using the analogue channels to do an I2C decode.

Firstly, 10Mpts seems to be about the most it can manage with about 30% active I2C data to decode. Although it might say "Too many events" on the main trace, you can still decode in the zoom trace.

Secondly, the sampling rate of the scope refers to the analogue sampling rate, not the LA sampling rate, which is 1/8 of the analogue sampling rate. The minimum LA sampling rate that works reliably for 100kbps is 625kSa/s, or 5MSa/s analogue sampling rate. Correspondingly, the memory depth of the LA at a given analogue sampling rate will be 1/8 of the analogue memory depth (e.g., 100k analogue samples will be 12.5k LA samples).

With this in mind, you can decode in a single sweep about 2s of 100kbps I2C. with a 5MSa/s analogue sampling rate and 10Mpts memory. That should be more than enough for your example.



Now there are other ways around the problem, but knowledge of the limitations mentioned above is a good starting point.

Option 1 is to simply introduce a trigger delay until the packet you want is captured. This is a bit hit and miss, but on a simple scenario that might be all you need.

Option 2 is to use the Record functionality (also known as segmented memory on Keysight scopes). In an example I just tried, I could capture 9,175 I2C packet bursts over a period of 4.5 minutes. Each packet burst is 34 bytes long (16 I2C starts/restarts). I set up a pulse trigger of 2ms on SCL, so each recording is started once the bus has been dormant for >2ms. Note I had to use an analogue channel for the trigger, as LA channels don't seem to work with a pulse trigger. Each recording was set for 100kpts at 5MSa/s analogue sampling rate (625kbps LA sampling rate).

The trick of Option 2 is to set up the timebase for your longest packet burst. To deal with longer packet bursts, you'll need a longer timebase and more sampling points, and so this will reduce the total number of recordings (or packet bursts) available to you.









While using a USB streaming LA is a viable alternative for this scenario, once you understand the scope it should do what you desire. Using a scope for this kind of work is a different workflow to using an LA: with a scope it's all about the triggers, whereas with a USB streaming LA it's a data grab and post processing. There are pros and cons to both, and it's not really a one-size-fits-all. I use both on a daily basis, but typically I go for the MSO first as I've been brought up with scopes and triggers. YMMV, I can see the friction of a learning curve around the scope might well be a turn off.

[Howardlong]

What PIC is the OP using? I don't mind having a look at the code if it's XC8. It's also reasonably likely I may well have their device in stock.

[jerryk]

Shouldn't SCL be HIGH between packets? 

Both LCD libraries contained errors causing SCL to be low between packets.

Here is one of the errors:

Code: [Select]

void I2C_Master_Stop()
{
  I2C_Master_Wait();
  //PEN1 = 2; Typo in code caused SCL to remain low between packets
  PEN2 = 1;
}
The error in the other library is more involved but easily fixed.

@Howardlong I sure appreciate the info in your post and the offer to look at the code but at the moment I want to attempt to get this LCD running via my on coding follies as it sticks better in the brain if I struggle my way toward success.

Bottom line of this thread is now that I can zoom in on decoded packets I think I can get this I2C LCD working on both libraries.

Thanks everyone - Jerry

[tggzzz]

While using a USB streaming LA is a viable alternative for this scenario, once you understand the scope it should do what you desire. Using a scope for this kind of work is a different workflow to using an LA: with a scope it's all about the triggers, whereas with a USB streaming LA it's a data grab and post processing. There are pros and cons to both, and it's not really a one-size-fits-all. I use both on a daily basis, but typically I go for the MSO first as I've been brought up with scopes and triggers. YMMV, I can see the friction of a learning curve around the scope might well be a turn off.

With a decent LA it is all about triggers and filters.

The filters allow you to ignore irrelevant time-domain noise, and concentrate on digital domain signals.

Simplest example: only capture data at a clock transition, since anything between clock transitions is irrelevant.
Next example: ignore any of that data that isn't to/from a specified device.
And continue adding filters so you can concentrate on the useful information.

Protocol analysers do the same, but with messages not bits.

[Howardlong]

While using a USB streaming LA is a viable alternative for this scenario ...  a scope for this kind of work is a different workflow to using an LA: with a scope it's all about the triggers, whereas with a USB streaming LA it's a data grab and post processing.

With a decent LA it is all about triggers and filters.

TBF, I think it's clear that the context is regarding USB streaming LAs, not the "decent LA" you're referring to!

Furthemore, the type of triggers you'll find on your average USB streaming LA typically amount to an edge or pattern... and that's it.

[tggzzz]

While using a USB streaming LA is a viable alternative for this scenario ...  a scope for this kind of work is a different workflow to using an LA: with a scope it's all about the triggers, whereas with a USB streaming LA it's a data grab and post processing.

With a decent LA it is all about triggers and filters.

TBF, I think it's clear that the context is regarding USB streaming LAs, not the "decent LA" you're referring to!

Furthemore, the type of triggers you'll find on your average USB streaming LA typically amount to an edge or pattern... and that's it.

The trouble is that too many people will use such "bit recorders", think they are representative of logic analysers, and not realise the ways in which a good analyser can make their lives more enjoyable.

[Kean]

If this is a character LCD with an I2C interface via a I2C GPIO IC, then you will likely find that it is only using 4-bit mode.
Typically the 8-bit GPIO provide 4 data bits and 3 control signals to the parallel bus input of the LCD.
That would explain why you cannot find the letter "P" in the data stream.

[Howardlong]

If this is a character LCD with an I2C interface via a I2C GPIO IC, then you will likely find that it is only using 4-bit mode.
Typically the 8-bit GPIO provide 4 data bits and 3 control signals to the parallel bus input of the LCD.
That would explain why you cannot find the letter "P" in the data stream.

I was wondering this too... now I look at typical designs, I think you're very likely right.

They seem to use simple 8 bit I/O expanders, and that's it.