March 13, 2020 at 10:54 #27616
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:C++12345Master Slaves0xC0 0x00 -> (write slave 0x60)0xC1 <- 0x00 0x00 (read slave 0x60)0xC2 0x00 -> (write slave 0x61)0xC3 <- 0x00 0x00 (read slave 0x61)
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.
DavidMarch 13, 2020 at 11:05 #27619
I won’t let me upload the .dsf (for security reasons). I’ll try zipping it firstMarch 21, 2020 at 05:20 #27723
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-184.108.40.206.msi . It now supports 10-bit addressing mode and works better for zoomed-out signals.March 24, 2020 at 06:59 #27736
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.
DavidMarch 25, 2020 at 05:47 #27746
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.March 25, 2020 at 07:23 #27748
Fair enough. It was worth a try :). I keep trying to increase the setup time after clock stretching.
DavidMarch 25, 2020 at 10:03 #27749
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.March 26, 2020 at 02:08 #27753
No problem. We have fixed the issue in the following build: Analyzer2Go-220.127.116.11.msiMarch 26, 2020 at 16:43 #27762
Thanks for quick turnaround. It’s working great now.
DavidMarch 26, 2020 at 17:42 #27766
You must be logged in to reply to this topic.