We are getting ready to add Analyzer triggers to Logic 2 alpha. We would love to hear from people that use multiple analyzers and learn about how you might use analyzer triggers and if you would want to trigger on multiple analyzers.
In the multiple analyzer triggering use case the display would snap to the newest frame of any analyzer that was selected for the trigger.
We are planning on building these as visual triggers. So the primary use case is to be in looping mode and a new frame from an analyzer will be centered on the screen.
Thanks,
Neel
p.s.
If you prefer, you’re welcome to schedule a call with us here:
The use case that I see is the need for a sequential trigger using an analyzer. A typical use case would be triggering on the I2C analyzer on a data write to an address with a specific data pattern. This means triggering on the specific I2C address, the memory address which may be 8 - 32 bits (1-4 bus operations), then repeating the I2C address and starting the data write. Then the data.
Having analyzer trigger templates setup for a memory read, or write with optional data patterns for the address and data, and other devices (with or without internal register addresses) read/write optional data patterns would be helpful.
Another use case would be serial data patterns. For instance, loop until the serial port decoded “Trigger”, or a hex pattern (vs ASCII) for binary data.
Hopefully you will have triggers without analyzers such as certain patterns on different channels such as channel 0 high, channel 1 low, channel 2 low.
Hi Mark,
Thanks for giving me those great use cases.
Those are really helpful for me to understand the types of triggering you are looking for.
Could you let me know what problems you might be debugging in these scenarios?
Could you describe how you might use the data table in addition to triggering for these scenarios?
If you are open to it I’d love to hop on a call with you once we have a few concepts ready to get your feedback, would you be open to that?
The simple example is to trigger on a read or write to a specific I2C address when there are multiple I2C devices on the bus. Next, I want to look at what is being written to (or read from) the starting address in a memory at that address… These could be combined with the level of an unrelated channel to trigger the capture. I’ve had cases where the data read back from the memory is wrong. I don’t know if it is going in wrong, or coming out wrong, or not going in a all. I need to look at the write transaction and analyze it, then the read transaction and analyze it. This would require looking at both the protocols as well as the waveforms to see if there is a timing issue.
If I have an I2C transaction that occasionally fails at the hardware level. I would want to trigger on the failure. This could be an I2C read/write that should work, but hits a timeout or NAK from the device.
I would like to use the data table to look at the more complicated transactions. It is easier to look at the data block being written to a memory in that format rather than trying to scroll across the data at the top of a waveform. In the past, I’ve grabbed transactions in the data table, exported them to Excel, then used it to do further analysis. For example: I may have a set of data has a CRC at the end that is wrong for some reason. I would capture the data for the transaction, export that to Excel, then use it to calculate the CRC. Today, I cannot get the table out from the Logic GUI to import into Excel. It would be nice just to cut & paste the area I what from the GUI into Excel. The trigger would make the data I want always like up at the same place so it is easy to find each time. In the V1 GUI I had to export the data to a file, then import that into Excel. This was a pain, but at least I could do it.
For the serial example, it may not be some simple text that I’m trying to trigger on. It may be a transaction between two devices, and that may not be ASCII. I may have a protocol that starts with a character say the STX character. I want to capture the data starting with that character. Once again, it is easier to look at this transaction in the data table that the waveforms. If I see something odd, I might want to look at the waveform to see if it may be a hardware or timing issue such as baud rate being slightly off.
A slightly different scenario I had a while back was: I was interfacing with a GPS via I2C and the firmware had to read a particular address and it would return the number of bytes to read when data was ready. It may take 1 second or longer to return any value other than zero. Then the firmware would go read that many bytes from a different address in the GPS. I’d like to trigger on reading any value other than zero from that device address. I would then capture that transaction and the one that follows reading the data block.
Yes, I’m available to talk 1:1. Just let me know when you are ready.
This type of detail is really helpful for me, especially since I am new to Saleae.
My current thinking is that I’d like to work with our designer to come up with some concepts that dig in to these use cases. Then we can walk through the concepts with you can get your opinion on what you think. I’m hoping by end of next week we can have something to show you. I’ll reach out to you via email to coordinate the meeting time.
I really appreciate the time you are taking to help us make an amazing product.
I had previously brought up the idea that what I need is to set a trigger condition and then have it SLEEP afterwards until the next trigger condition. An example of this might be hunting for a specific condition where a chip select might be active and another signal like an INT might fall low. I want to see what happens on the SPI bus just before and just after the INT hits. But, say I want to leave Saleae on over the weekend to catch maybe 10 positive conditions.
Most analyzers can be triggered this way, but then they will record forever after this, and even Saleae cannot keep up with this. you would have a crashed hard drive before the weekend is out.
But, if you were able to set the conditions mentioned above and have maybe 300mS before the trigger and 500mS after, then sleep and wait for the next condition, then you could come in after the weekend and have 5 seconds of data, but see 10 instances of your trigger condition to go over and debug.
Thanks for sharing your use case as well. I see that you want to be able to capture multiple instances of this issue occurring. I think you can capture a single instance of this by using the Trigger settings for Capture duration after trigger and Trim pre-trigger data. It looks like you can go down to 1 sec on either side.
In your case there could be an additional option to repeat the trigger N number of times and also make the times be shorter before and after the trigger. Would that solve the problem for you?
It really would. Is this picture you are showing me from the new beta? I use Saleae almost every day and have spread the word inside the place so Honeywell CT has bought 6 of the 8 channel and 16 channel pros so far. But, I have 1.2.29 I am using and am unaware of this trigger capability.
Thanks for your reply so fast. Saleae is the absolute best. In fact, a year ago, I blew up my 7 or 8 year old original 16 channel ver1. I knew it was out of warranty and was willing to pay to have it fixed. Mark G. sent another out right away and just asked I put the blown one in a box and send it back. This is heroic service, and I will never forget it.
An idea that popped into my head when I read this was to open a new session window for each new trigger. That way if you have 5 triggers over the weekend, you would come back to 5 session windows. The pre-trigger and post-trigger capture lengths could be set like they are today, and each capture would be independent.
