Can the analyzer for i2c handle i2c fm+?

I have a device that appears to support i2c UFm. It appears the clock is running a hair over 12MHz (UFm doesn’t seem to impose a real limit from what I’ve read, though 10MHz was implied somewhere). I attempted to take a look at the signal with the i2c analyzer. It IS attempting to make sense of it, but I think its failing. I was wondering if anyone else has looked at any i2c UFm or any fm+ signaling with the i2c protocol analyzer. Unfortunately, there really aren’t many settings, though I’m not exactly sure there would be anything that would help. Sorry I can’t provide more details, but the system I’m working on isn’t internet connected (maybe I’ll eventually get WiFi out in the shop). The pcb is from a broken device, and I only recognize the stm32l476 on there. Short of pulling out the firmware (my next step), I am trying to just get a general sense of health of the system.

Could you post a saved capture here?

Also, if you’re not already, be sure to push the digital sampling rate to the limit for this. I don’t know about 12MHz I2C, but typically I2C needs fairly good timing resolution between the SDA and SCL lines even for fairly low clock speeds.

I’ll see what I can do about a saved capture. It takes up quite a bit of space. I might try to take just a section. As far as cranking it up, I set the sampling to 500MS/s … While that’s a fair amount of resolution, I know it can be a bit tricky if there is jitter in a clock or something. But that’s as high as I can push it. I believe it SHOULD be plenty. I did try lower clock rates to capture more data (the device is quite chatty). It seemed to produce the same results even at 125MS/s, so I’m guessing that was okay. When I first got a look at this signal, I was kind of shocked. I didn’t realize there was such a thing as 12MHz i2c, but i2c UFm seems to be an NXP standard of sorts. The pins I’m monitoring appear to be attached to PB6 and PB7 on the STM32, which appear to be i2c scl and i2c sda for i2c1. The user manual for the device DOES say it seems to support i2c fm+ … I don’t know if that includes UFm.

Btw,
What’s the procedure for uploading something larger than 4M? The capture is 16M.
Session 0-cut2.sal (89.6 KB)

Okay, this is a cut. It should be enough.

Woah, that’s not what I was expecting. There are almost no transitions on the SDA channel. Most of the transitions of the SDA channel are well centered in high pulses of SCL, which would be start and stop conditions, but there are a few transitions like this that appear nearly edge aligned:


Note 2ns is the resolution limit of the device, which means that transition could be coincident.

I do not understand why our I2C analyzer is trying to decode bytes after a stop condition.

I see 2 problems here, one with the recording and one with our software.

  1. the lack of SDA transitions is very odd. At the very least, we should see address bytes after start conditions. Are you sure you’re recording the correct signals, and the connection good?
  2. Our I2C analyzer expects a 9th ACK/NAK bit. I didn’t find the official documentation for i2c UFm, but one website I visited said that slaves to not sent an acknowledge bit. I’m not sure if that applies to address bytes, data bytes, or both, but in any case, our analyzer always tries to decode 9 bits at a time.

You can use our SPI analyzer to decode generic synchronous serial data, however that probably won’t help much here because it appears the I2C clock is always running, rather than only running when a transaction is taking place. Normally you would set one of the SPI channels and the Enable channel to “none” to decode generic single data signal synchronous serial. Also, if the address frame contains 9 bits, while all other frames contain 8 bits, neither the I2C nor the SPI analyzer will be able to handle that framing.

If the SPI analyzer could decode the bits correctly, it would be pretty quick to re-frame the data in a HLA, which I’d be happy to help with. However at this point, the recorded data doesn’t really make sense to me.

It didn’t make sense to me either. Thanks for taking a look. I tried applying a UART to it thinking that the signalling was asynchronous and that the clock was just there to provide “clocking” to the external chip the stm32 is communicating with. I tried with various baud rates, but there are always several framing errors. I originally thought the connection should have been SPI, but I can only really find 2 signals connected to the stm32…the 12MHz signal, and the other signal. I’ll have to check more carefully, but other pins I’ve monitored show nothing. The only thing I was latching on to was the start conditions. From what I read though, the i2c UFm doesn’t really have start conditions (though the NXP manual I was looking at seems, from the diagrams, to indicate that they still do have those). This is SOMETHING on i2c UFm here. But, the more I look at this, the less it looks like even i2c UFm. I just don’t see any other lines connected to the second chip that appear to be signalling anything.

Okay, I was correct when I said: “…thinking that the signalling was asynchronous…” … It is… Its just a UART at a baud rate of 33187 Hz. I suspect they are trying to use the 32KHz oscillator or something similar to generate a clock to the device. At any rate, that part appears to be working properly. Time to see where it’s broke… Thanks again.

1 Like