Unable to decode i2c @ 350kHz

Sysprogs forums Forums Analyzer2Go Unable to decode i2c @ 350kHz

Tagged: 

This topic contains 9 replies, has 2 voices, and was last updated by  support 5 months, 3 weeks ago.

Viewing 10 posts - 1 through 10 (of 10 total)
  • Author
    Posts
  • #27616

    david_home
    Participant

    Hi Support,

    I’m using a Nucleo-F746ZG to analyse an I2C bus.  The bus is running in Fast Mode and a clock speed of about 350kHz.  It seems to get the very first start bit correctly, but from then on fails to decode correctly.  It fails to decode the address bits, r/w bit, ACK/NAK of the first byte.  The bus consists of 1 Master and 4 Slaves.  They are address 0x60 – 0x63 (0xC0-0xC6 after shifting left for the r/w bit).  I’m expecting to see:

    I have tried changing to standard mode, but it only logs the first frame (0xC0 0x00) and then stops.  The waveform continues to be recorded above, but only a single frame in the Hex text box.

    I’ve attached the waveform to this message.  Let me know if you need the workspace too.

    Cheers

    David

     

     

     

    • This topic was modified 6 months, 1 week ago by  david_home.
    • This topic was modified 6 months, 1 week ago by  david_home.
    #27619

    david_home
    Participant

    I won’t let me upload the .dsf (for security reasons).  I’ll try zipping it first

     

    Attachments:
    You must be logged in to view attached files.
    #27723

    support
    Keymaster

    OK, we have investigated the problem. It looks like the I2C peripheral you are using is doing the clock stretching and it releases the SCL clock at the same time as pulling SDA down to acknowledge the transmission:

    At least, at the current sampling frequency, it looks like SDA changes exactly at the rising edge of SCL (when it should be stable), so Analyzer2Go aborts the I2C parsing.

    Our best advice here would be to try using a faster board (e.g. CYUSB3KIT) that will be able to tell the difference between the times when SDA and SCL change.

    P.S. Although it doesn’t fix this issue, we have improved our I2C parser in the following build: Analyzer2Go-2.1.0.21.msi . It now supports 10-bit addressing mode and works better for zoomed-out signals.

    Attachments:
    You must be logged in to view attached files.
    #27736

    david_home
    Participant

    Thank you for looking at this issue for me.  I noticed after the clock stretching the SDA and SCL toggling at the same time too.  I was hoping it was just the resolution of the graph, but by your reckoning they changed on the same sample point.  I measured 300ns between the SDA going low and the SDC going high.  I assume that time is too short to separate the two signal changes, so it would appear to A2G that the peripheral is violating the setup time.  With that accepted, is there anyway you can just take the ‘new’ value of SDA on the rising edge of SCL?

    The slaves are actually  STM32F0’s so I’ll see if there is a way of extending the time between SDA going low and the SCL going high.  Unfortunately, the timing register looks quite complicated.

    Thanks for the updated software.  I haven’t tried it yet, but I’ll let you know how it goes.

    Cheers

    David

    #27746

    support
    Keymaster

    Sorry, trying to assume the new value instead of verifying a stable value would break the current I2C parsing logic. We might be able to add an option for this in one of the future releases, but we wouldn’t promise it currently.

    As a quick-and-dirty workaround, please try selecting a several clock cycles in the SCL signal and clicking the clock pulse icon. This will print the stable values of the SDA signal, making it easier to read.

    #27748

    david_home
    Participant

    Fair enough.  It was worth a try :).  I keep trying to increase the setup time after clock stretching.

    Cheers

    David

    #27749

    david_home
    Participant

    Hi Support, Good news!  I have managed to increase the setup time and hold time so I don’t see any clashes with the clock rising edge.  However, it is still only decoding the first frame.  Can you tell me why the other frames have not been decoded?

    I’ve attached the data file.

    Attachments:
    You must be logged in to view attached files.
    #27753

    support
    Keymaster

    No problem. We have fixed the issue in the following build: Analyzer2Go-2.1.0.28.msi

    #27762

    david_home
    Participant

    Thanks for quick turnaround.  It’s working great now.

    Cheers

    David

    #27766

    support
    Keymaster

    No worries. BTW, we have officially released Analyzer2Go 2.1 that includes this fix, adds support for 5 more STM32 boards, and introduces a few more features.

    You can read more about it here: https://sysprogs.com/w/analyzer2go-2-1-is-out/

Viewing 10 posts - 1 through 10 (of 10 total)

You must be logged in to reply to this topic.