Logic 2.3.9 is a bug fix release, that covers several important CPU utilization bugs. Thanks to everyone who reported the problem, sent in captures, and worked with us to help find the root cause.
A quick note on the fix for the decoding problem with I2C and Parallel analyzers when decoding data as it is recorded. We were not able to directly reproduce the issue with I2C. If you see a problem where I2C results are missing, and extra start/stop bits are added instead of decoded bytes, please let us know! We’re pretty sure it’s fixed, but we haven’t been able to verify it directly. The bug requires two things - one, it only occurs when running the I2C analyzer on a live capture. It does not occur if you run the I2C analyzer on data after recording is finished. Second, it is sensitive to the specific timing of the I2C data (possibly related to long delays between bytes, but we’re not 100% sure). Also, if you’ve seen this issue in older releases, but not in 2.3.9, please let us know! As far as we can tell, this bug has been in the Logic 2 software at least all year, possibly since we added analyzers to Logic 2.
A note on CPU usage - you should see high CPU usage while analyzers are processing, and while data table indexing is performed. For an analyzer with 100,000 frames produces, indexing should take less than a minute after the analyzer finishes processing. We will be adding an indexing progress indication soon. Once indexing is complete, the CPU usage should drop.
Bug fixes
Fixed CPU utilization problem with I2C analyzer.
Fixed decoding problem with I2C and Parallel analyzers when decoding data as it is recorded.
Fixed CPU utilization problem that occurred when removing an analyzer.
Fixed CPU utilization problem regarding analyzer data table results population.
Awesome! I’m very pleased that the CPU utilization is down now, particularly when running the notebook on batteries. The UART analyzer caused this for me but might be in conjunction with the data table. Anyway, it’s fixed.
Thank-you to the team!
Note: I think I already have a reasonable solution for this, but thought I would ask to see if there is another more obvious one…
Right now I am playing with a simple OV7670 camera and trying to make it work reasonably on a Teensy 4.1… So Pulled out my older Logic 16 to have enough IO pins (8 daga pins, plus 4 other main signals, plus I2C, and I use the last 2 for debug…
Example:
I am trying to make sure of when it is trying to read in the 8 data bits, to verify it is on the right edge of the clock (currently it is not…) and then to see what the data byte is for the 8 data pins.
So question is what is the best way to look and see what the value of the 8 data bits are at the different edges. What I have now is to use Add Marker command which gives me a vertical line, which I can move to the edges of the clock and then see where in each of the data line what the value at that time is…
Question is any better solution? Obviously a analyzer or an HLA would be good, to see each byte, but…
EDIT: I should mention that I put the marker at an edge of Channel 14, where in the code I added a digitalToggleFast when then code read in the IO port associated with the data pins.
Channel 10 is the clock pin from camera and I believe you are suppose to read on the rising edge, not the trailing edge which I suspected the current code was doing.
@KurtE Our Simple Parallel Analyzer might do the trick (if I understood your requirement properly). In the analyzer’s settings, you would set it up as follows:
8 data pins configured for 8 channels of your choosing
clock pin configured for another channel
set it to rising edge or falling edge detection (depending on which you want to test first)
Once the analyzer is added, you’ll see arrows on the clock signal as to where the sampling is taking place, as well as the decoded data from the 8 data channels at the time (you can set the radix for the Parallel analyzer to binary or hex for easy reading). You could set it to rising edge first, compare the readings with your OV7670/Teensy, then set it to falling edge and do the same.
Feel free to attach your .sal file too. I’m happy to demonstrate it on your .sal file if that helps as well.
To help visualize the point where data is being sampled it would be nice to provide a marker line at the clock edge across the data channels being sampled. That would allow a really quick check on the setup and hold time margins by zooming in an appropriate amount and eyeballing data edges near the clock edge.
the Simple Parallel works well for this. It nicely shows the marks in the 8 data.
Note: I mostly use Hex display, but thought I would try the binary as you mentioned it. For me, I am not sure how much I would use binary mode as it takes up way to much space, and for example in the main analyzer capture area, when I am fully zoomed in, it only shows 0b0 as the rest wont fit. Yes you can hover the cursor over it to see more and in table output which is nice the values displayed have a whole lot of zeros for 64 bits, before I get to the actual data which is only 8 bits: 0b0000000000000000000000000000000000000000000000000000000010000010
And that column display is truncated to show the left most bits
Note: I should also mention that the Hex mode also truncates the view data as well, but not sure what you might do about it, other than if you know the capture is only 8 bits than when showing hex only try to output 0x82 instead of 0x0082
Oh you’re right about the hex/bin display not truncating properly! That looks terrible… We should get that fixed. I’ll send this feedback over to our developers to get it on the backlog.
@P.Jaquiery Thanks for that. I’m not sure we would implement something like this right away since the parallel analyzer could probable do a similar job. Feel free to get this up on the ideas page in case I missed a key detail that the Parallel Analyzer may not readily solve.
Sorry in advance, I thought I had a sure way to hang/crash… And I thought I had one captured, but after starting to document it, this time it recovered… Again more with the parallel analyzer with camera.
I will often times just start off the capture, switch window to Arduino terminal window and enter a command in this case to try to do DMA capture from the camera… After it completes I stop the capture (Note it will sometimes stop on own with USB timeout error, but it is after the data I want is captured…)
So it might look like:
and then I use the trim command using the timing marks as the end points. At this point I try to zoom in to the data that is left and then sometimes the most I can zoom into leaves me with a display that looks like:
If I then try to do a new capture, the capture does not run, if I close the app and try to rerun it, it does not find the Logic Analyzer. Sometimes if I turn off the USB port and turn it back on (Using USB hub with buttons for each port), it comes back, sometimes not, in either case I here the tones on Windows machine for USB device added or removed. Many times when that does not work, I can move the device to different USB port and it works again…
But in this case I thought I had it reproduced but after I let the window sit for a few minutes in the state of the last picture, while saving away the images and like, the window recovered.
My guess is the app was maybe busy in doing memory management of trying to trim the data. Including the Simple Parallel Analyzer which may or may not have previously completed before the trim of data operation was done.
Again sorry, was not sure if I should report issue until I had a fail proof example.
@KurtE Thanks for reporting that. No worries at all on not having conclusive evidence, but that definitely looks like some sort of rendering bug from trimming. You might be on to something when you mentioned the trimming processing could be at play.
I’d like to get a formal bug report in, so we can get this investigated on our backlog. Would you mind opening a ticket via link below?
In the message, include the following:
the link to this discuss forum: Logic 2.3.9 (that way I’ll know right away that it’s you)
a copy of your capture (.sal) file attached. If you can, please try and take a new capture with all the data included (untrimmed). We’d like to try trimming it to around the same section to see if we can reproduce it. We’ll also try on our own captures.
I’m very pleased that the CPU utilization is down now, particularly when running the notebook on batteries. 
The UART analyzer caused this for me but might be in conjunction with the data table. Anyway, it’s fixed.
