Products > Test Equipment
Rigol MSO5074 Logic Analyzer issues
<< < (4/7) > >>
Fungus:
Shouldn't SCL be HIGH between packets?  :popcorn:

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:

--- Quote from: Fungus on September 23, 2024, 10:52:08 pm ---Shouldn't SCL be HIGH between packets?  :popcorn:

--- End quote ---

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

Here is one of the errors:

--- Code: ---void I2C_Master_Stop()
{
  I2C_Master_Wait();
  //PEN1 = 2; Typo in code caused SCL to remain low between packets
  PEN2 = 1;
}
--- End code ---

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
Navigation
Message Index
Next page
Previous page
There was an error while thanking
Thanking...

Go to full version
Powered by SMFPacks Advanced Attachments Uploader Mod