USB LS and FS Analyzer been enhanced?

As was discussed a few times during the Logic 2 software beta cycle, including:

There are times when I try to use the Analyzer to capture, either protocol startups or data.

Today for example would like to capture an MTP file transfer to see if/when a USB data packet is either not sent or something wrong with one or more 64 byte data packet

Problem is with current analyzer there is so much other data, that I lose the tree in the forest.

What I have typically done in the past was to have to save report out to file, then use grep to find all of the lines that cantain data. I usually use the linux greap as to also capture the line before the data line.
Then I need to edit this file to remove a bunch of other stuff…

Would be nice to have a version of capture that does this for us.

Also were HLA hooks setup for this analyzer?

Thanks
Kurt

Hey Kurt, sorry for the trouble with that. Yeah, the USB analyzer can get pretty busy. Unfortunately, our USB analyzer is not supported by HLAs yet. Creating an HLA would have been a viable solution for this. The supported analyzers are listed below.

Can you give me an idea of what kind of data you typically search for? Allowing the ability to search a sequence of bytes could also be a step towards that direction (per the idea post we’re tracking below):

Apolgies we don’t have an immediate solution for this.

Thanks,

I showed an example back in I believe the 2nd posting of the thread:

Where I boiled down 1.9 million line output, to a few 100 lines of useful (to me) information.

That ended up looking something like:

|23.21607064|IN|0x02|0x18|0x48 0x20 0x53 0x00 0x4F 0x00 0x71 0x00 0xA1 0x11 0xC0 0x00 0x81 0x7C 0x81 0x7C 0x08 0x00 0x48 0x00 0x00 0xA0 0x7F 0xFC 0x0E 0x00 0x00 0x00 0x05 0x00 0x81 0x0A 0x7C 0x1E 0x1A 0x00 0x00 0x00 0x00 0x00 0x00 0x09 0x00 0x00 0x00 0x00 0x80 0x00 0x00 0x00 0x80 0x00 0x00 0x00 0x00 0x80 0x00 0x00 0x00 0x80 0x00 0x00 0x00 0x00|
|23.21707062|IN|0x02|0x18|0x80 0x00 0x00 0x00 0x80 0x00 0x00 0x00 0x00 0x80 0x00 0x00 0x00 0x80 0x00 0x00 0x00 0x00 0x00 0xC3 0x7D 0xE1 0x8C|
|23.21807067|IN|0x02|0x18|0x48 0x20 0x53 0x00 0x4F 0x00 0x71 0x00 0xA1 0x11 0xC0 0x00 0x81 0x7C 0x81 0x7C 0x08 0x00 0x4C 0x00 0x00 0xF7 0x80 0xFC 0x0E 0x00 0x00 0x00 0x05 0x00 0x69 0x0A 0x83 0x1E 0x09 0x00 0x00 0x00 0x00 0x00 0x00 0x09 0x00 0x00 0x00 0x00 0x80 0x00 0x00 0x00 0x80 0x00 0x00 0x00 0x00 0x80 0x00 0x00 0x00 0x80 0x00 0x00 0x00 0x00|

Note: the copy and paste from the other thread sort of changed it slightly… But does show the point.

Sort of boiled down to In/out (which channel) how many bytes, and the data. Sometimes I leave the time stamp other times not.

Thanks again

Kurt

P.S. - Luckily yesterday was able to find where the messages were being lost to without resorting to this. But still would be great to have some solution for the next time

1 Like

As I only see one branch of the usb_analyzer: GitHub - saleae/usb-analyzer: Saleae USB Analyzer

I am guessing that there has not been much progress on supporting some different output formats or support for HLAs.

So I started wondering how hard it might be to add an HLA interface for the analyzer…
So I forked, and created a new Alpha branch. I merged in some of the external changes for alpha from the Serial and/or SPI analyzer and have it building, where I can UseFrameV2.

And started trying to add V2 frames most everywhere a V1 frame is… and it does build.
Have not done the USBControlTransfers yet.

But also now wondering about how the V2 packets should be done versus V1, for example if you look at:

U64 USBPacket::AddPacketFrames( USBAnalyzerResults* pResults, USBFrameFlags flagPID )
{
    AddSyncAndPidFrames( pResults, flagPID );

    // make the analyzer frames for this packet
    Frame f;
    f.mFlags = FF_None;
    FrameV2 fv2;
    const char* fv2_type;

    // do the payload & CRC frames
    if( IsTokenPacket() || IsSOFPacket() )
    {
        // address/endpoint  or  frame number
        f.mStartingSampleInclusive = *( mBitBeginSamples.begin() + 16 );
        f.mEndingSampleInclusive = *( mBitBeginSamples.begin() + 27 );

        // is this a SOF packet?
        if( mPID == PID_SOF )
        {
            f.mType = FT_FrameNum;
            f.mData1 = GetFrameNum();
            f.mData2 = 0;
            fv2.AddInteger( "frameNum", ( U8 )f.mData1 );
            fv2_type = "frame";
        }
        else
        {
            f.mType = FT_AddrEndp;
            f.mData1 = GetAddress();
            f.mData2 = GetEndpoint();
            fv2.AddInteger( "addr", ( U8 )f.mData1 );
            fv2.AddInteger( "endpoint", ( U8 )f.mData2 );
            fv2_type = "addrendp";
        }

        pResults->AddFrame( f );
        pResults->AddFrameV2( fv2, fv2_type, *( mBitBeginSamples.begin() + 16 ), *( mBitBeginSamples.begin() + 27 ) );

        // CRC5
        f.mStartingSampleInclusive = *( mBitBeginSamples.begin() + 27 );
        f.mEndingSampleInclusive = mBitBeginSamples.back();

        f.mType = FT_CRC5;
        f.mData1 = mCRC;
        f.mData2 = CalcCRC5( GetLastWord() & 0x7ff );
        pResults->AddFrame( f );

        FrameV2 frame_v2_crc;
        frame_v2_crc.AddInteger( "crc", ( S64 )f.mData1 );
        frame_v2_crc.AddInteger( "ccrc", ( S64 )f.mData2 );
        pResults->AddFrameV2( frame_v2_crc, "crc5", *( mBitBeginSamples.begin() + 27 ), mBitBeginSamples.back() );
    }
    else if( IsDataPacket() )
    {
        // raw data
        FrameV2 fv2;
        size_t bc;
        f.mType = FT_Byte;
        f.mData2 = 0;
        for( bc = 2; bc < mData.size() - 2; ++bc )
        {
            f.mStartingSampleInclusive = *( mBitBeginSamples.begin() + bc * 8 );
            f.mEndingSampleInclusive = *( mBitBeginSamples.begin() + ( bc + 1 ) * 8 );
            f.mData1 = mData[ bc ];

            pResults->AddFrame( f );
            fv2.AddByte( "data", mData[ bc ] );
            pResults->AddFrameV2( fv2, "result", *( mBitBeginSamples.begin() + bc * 8 ), *( mBitBeginSamples.begin() + ( bc + 1 ) * 8 ) );
        }

        AddCRC16Frame( pResults );
    }

    if( mPID != PID_PRE )
        AddEOPFrame( pResults );

    pResults->CommitResults();

    return mSampleEnd;
}

Which does build, I am doing a 1 to 1 V1 to V2 message.

But wondering for example:
if this should instead simply generate one or a few messages.
Where all the data should be just one item,
with a bytearray for a “data” item in the v2 frame. Not sure if things like SOF or CRC should be separate or again just another field.

So far just playing, I have not yet tried plugging it in to to the analyzer to see if it goes boom or generates data

Thoughts?

@timreyes - quick questions on LLA

I am assuming this is still a single path… i.e. nothing like , or ; between multiple

If I want work on a different one, but still use one like SPIEx, I probably just copy the
SPIEx one to where all of the others are, including the ones that you install. Which in my case is:
D:\Program Files\Logic\resources\windows\Analyzers

If I am working (Playing) with updates to one of your analyzers (this case USB) and
I update that path to where it builds, What will the analyzer list do with two with same name?
Fail? Show Both, or one takes priority over the other?

Thanks

Edit - Answered last question:
image

Was able to load experimental one by editing:

const char* GetAnalyzerName()
{
    return "USB(alpha) LS and FS";
}

Changed name…

Sorry I am mostly talking to self… :wink:

Making some maybe progress:

Will play more with HLA to see if it talks…

Sorry another quick update…

I have verified that I can talk to it with an HLA…
Here is some output from the HLA


Probably all for today

@KurtE Good to hear you’re making progress! For your question below:

I am assuming this is still a single path… i.e. nothing like , or ; between multiple

We definitely need to improve this to allow multiple source folder locations per LLA (similar to how we handle HLAs right now). We had another user submit a similar feature request below fairly recently.

Thanks.

I am not sure of best way to proceed. That is, will Saleae wish to incorporate some/all the FrameV2 for USB stuff into the official released version… And if so what is the best way to proceed… So I opened up an issue on the library: Support High level Analyzers using FrameV2 · Issue #3 · saleae/usb-analyzer · GitHub

My Fork/Branch is up at: GitHub - KurtE/usb-analyzer at alpha
I have also pushed up my WIP HLA using it: GitHub - KurtE/Saleae_USB_Data_Packets_HLA: USB Data Packets using my Alpha version of USB LS and FS

I have the bubbles and table stuff showing up reasonably well:

The print output is pretty well setup to output to something like excel:
Note: I trimmed this down as it included a lot of mouse inputs at end …
Which I would typically prune when I used it.
But it output I believe 2048 lines. But after pruning down to maybe 50-75 lines…

SETUP , DATA0 , 0x0 , 0x0 ,  0x80 0x6 0x0 0x1 0x0 0x0 0x8 0x0
IN , DATA1 , 0x0 , 0x0 ,  0x12 0x1 0x10 0x1 0x0 0x0 0x0 0x8
SETUP , DATA0 , 0x0 , 0x0 ,  0x0 0x5 0x1 0x0 0x0 0x0 0x0 0x0
SETUP , DATA0 , 0x0 , 0x1 ,  0x80 0x6 0x0 0x1 0x0 0x0 0x12 0x0
IN , DATA1 , 0x0 , 0x1 ,  0x12 0x1 0x10 0x1 0x0 0x0 0x0 0x8
IN , DATA0 , 0x0 , 0x1 ,  0x8a 0x25 0x36 0x0 0x9 0x1 0x1 0x2
IN , DATA1 , 0x0 , 0x1 ,  0x0 0x1
SETUP , DATA0 , 0x0 , 0x1 ,  0x80 0x6 0x0 0x3 0x0 0x0 0xfc 0x1
IN , DATA1 , 0x0 , 0x1 ,  0x4 0x3 0x9 0x4
SETUP , DATA0 , 0x0 , 0x1 ,  0x80 0x6 0x1 0x3 0x9 0x4 0xfc 0x1
IN , DATA1 , 0x0 , 0x1 ,  0x16 0x3 0x53 0x0 0x49 0x0 0x4e 0x0
IN , DATA0 , 0x0 , 0x1 ,  0x4f 0x0 0x57 0x0 0x45 0x0 0x41 0x0
IN , DATA1 , 0x0 , 0x1 ,  0x4c 0x0 0x54 0x0 0x48 0x0
SETUP , DATA0 , 0x0 , 0x1 ,  0x80 0x6 0x2 0x3 0x9 0x4 0xfc 0x1
IN , DATA1 , 0x0 , 0x1 ,  0x26 0x3 0x57 0x0 0x69 0x0 0x72 0x0
IN , DATA0 , 0x0 , 0x1 ,  0x65 0x0 0x64 0x0 0x20 0x0 0x47 0x0
IN , DATA1 , 0x0 , 0x1 ,  0x61 0x0 0x6d 0x0 0x69 0x0 0x6e 0x0
IN , DATA0 , 0x0 , 0x1 ,  0x67 0x0 0x20 0x0 0x4d 0x0 0x6f 0x0
IN , DATA1 , 0x0 , 0x1 ,  0x75 0x0 0x73 0x0 0x65 0x0
SETUP , DATA0 , 0x0 , 0x1 ,  0x80 0x6 0x0 0x2 0x0 0x0 0x9 0x0
IN , DATA1 , 0x0 , 0x1 ,  0x9 0x2 0x3b 0x0 0x2 0x1 0x0 0xa0
IN , DATA0 , 0x0 , 0x1 ,  0xf0
SETUP , DATA0 , 0x0 , 0x1 ,  0x80 0x6 0x0 0x2 0x0 0x0 0x3b 0x0
IN , DATA1 , 0x0 , 0x1 ,  0x9 0x2 0x3b 0x0 0x2 0x1 0x0 0xa0
IN , DATA0 , 0x0 , 0x1 ,  0xf0 0x9 0x4 0x0 0x0 0x1 0x3 0x1
IN , DATA1 , 0x0 , 0x1 ,  0x2 0x0 0x9 0x21 0x11 0x1 0x0 0x1
IN , DATA0 , 0x0 , 0x1 ,  0x22 0x47 0x0 0x7 0x5 0x81 0x3 0x8
IN , DATA1 , 0x0 , 0x1 ,  0x0 0x1 0x9 0x4 0x1 0x0 0x1 0x3
IN , DATA0 , 0x0 , 0x1 ,  0x1 0x1 0x0 0x9 0x21 0x11 0x1 0x0
IN , DATA1 , 0x0 , 0x1 ,  0x1 0x22 0xd5 0x0 0x7 0x5 0x82 0x3
IN , DATA0 , 0x0 , 0x1 ,  0x8 0x0 0x1
SETUP , DATA0 , 0x0 , 0x1 ,  0x0 0x9 0x1 0x0 0x0 0x0 0x0 0x0
SETUP , DATA0 , 0x0 , 0x1 ,  0x81 0x6 0x0 0x22 0x0 0x0 0x47 0x0
IN , DATA1 , 0x0 , 0x1 ,  0x5 0x1 0x9 0x2 0xa1 0x1 0x9 0x1
IN , DATA0 , 0x0 , 0x1 ,  0xa1 0x0 0x5 0x9 0x19 0x1 0x29 0x5
IN , DATA1 , 0x0 , 0x1 ,  0x15 0x0 0x25 0x1 0x75 0x1 0x95 0x5
IN , DATA0 , 0x0 , 0x1 ,  0x81 0x2 0x95 0x3 0x81 0x1 0x5 0x1
IN , DATA1 , 0x0 , 0x1 ,  0x9 0x30 0x9 0x31 0x16 0x0 0x80 0x26
IN , DATA0 , 0x0 , 0x1 ,  0xff 0x7f 0x75 0x10 0x95 0x2 0x81 0x6
IN , DATA1 , 0x0 , 0x1 ,  0x9 0x38 0x15 0x80 0x25 0x7f 0x75 0x8
IN , DATA0 , 0x0 , 0x1 ,  0x95 0x1 0x81 0x6 0x5 0xc 0xa 0x38
IN , DATA1 , 0x0 , 0x1 ,  0x2 0x95 0x1 0x81 0x6 0xc0 0xc0
SETUP , DATA0 , 0x0 , 0x1 ,  0x21 0xa 0x0 0x0 0x0 0x0 0x0 0x0
IN , DATA0 , 0x1 , 0x1 ,  0x0 0x1 0x0 0x0 0x0 0x0 0x0
IN , DATA1 , 0x1 , 0x1 ,  0x0 0x1 0x0 0x0 0x0 0x0 0x0
IN , DATA0 , 0x1 , 0x1 ,  0x0 0x1 0x0 0xff 0xff 0x0 0x0
IN , DATA1 , 0x1 , 0x1 ,  0x0 0x1 0x0 0x0 0x0 0x0 0x0
IN , DATA0 , 0x1 , 0x1 ,  0x0 0x1 0x0 0xff 0xff 0x0 0x0
IN , DATA1 , 0x1 , 0x1 ,  0x0 0x1 0x0 0x0 0x0 0x0 0x0
IN , DATA0 , 0x1 , 0x1 ,  0x0 0x2 0x0 0x0 0x0 0x0 0x0
IN , DATA1 , 0x1 , 0x1 ,  0x0 0x1 0x0 0xff 0xff 0x0 0x0
IN , DATA0 , 0x1 , 0x1 ,  0x0 0x1 0x0 0x0 0x0 0x0 0x0
IN , DATA1 , 0x1 , 0x1 ,  0x0 0x2 0x0 0xff 0xff 0x0 0x0
IN , DATA0 , 0x1 , 0x1 ,  0x0 0x1 0x0 0x0 0x0 0x0 0x0
IN , DATA1 , 0x1 , 0x1 ,  0x0 0x2 0x0 0xff 0xff 0x0 0x0
IN , DATA0 , 0x1 , 0x1 ,  0x0 0x2 0x0 0x0 0x0 0x0 0x0
...

Which beats looking through in this case >43K lines, some case like 200K lines like:

Time [s],PID,Address,Endpoint,Frame #,Data,CRC
6.191137532000000,SOF,,,0x441,,0x02
6.192137538000000,SOF,,,0x442,,0x0A
6.193137546000000,SOF,,,0x443,,0x15
6.194137554000000,SOF,,,0x444,,0x1A
6.195137560000000,SOF,,,0x445,,0x05
6.196137568000000,SOF,,,0x446,,0x0D
6.197137576000000,SOF,,,0x447,,0x12
6.198137584000000,SOF,,,0x448,,0x13
6.199137592000000,SOF,,,0x449,,0x0C
6.200137600000000,SOF,,,0x44A,,0x04
6.201137606000000,SOF,,,0x44B,,0x1B
6.201140706000000,SETUP,0x00,0x00,,,0x02
6.201143806000000,DATA0,,,,0x80 0x06 0x00 0x01 0x00 0x00 0x08 0x00,0x94EB
6.201152438000000,ACK,,,,,
6.201155838000000,IN,0x00,0x00,,,0x02
6.201159118000000,NAK,,,,,
6.201162172000000,IN,0x00,0x00,,,0x02
6.201165464000000,NAK,,,,,
6.201168406000000,IN,0x00,0x00,,,0x02
6.201171644000000,NAK,,,,,
6.201174572000000,IN,0x00,0x00,,,0x02
6.201177822000000,NAK,,,,,
6.201180806000000,IN,0x00,0x00,,,0x02
6.201184086000000,NAK,,,,,
6.201187038000000,IN,0x00,0x00,,,0x02
6.201190348000000,NAK,,,,,
6.201193272000000,IN,0x00,0x00,,,0x02
6.201196526000000,NAK,,,,,
6.201199438000000,IN,0x00,0x00,,,0x02

And this mouse produces a lot less data than others…

Unfortunately, we don’t have a concrete date for this yet, but we do want to eventually convert all of our existing analyzers over to FrameV2 at some point. I’m actually meeting with the team tomorrow and I can add this to our discussion list. I’ll keep you updated.