- This topic has 9 replies, 2 voices, and was last updated 4 years, 1 month ago by
.
-
Posts
-
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:
Master Slaves 0xC0 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.
Cheers
David
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.
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
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.
Fair enough. It was worth a try :). I keep trying to increase the setup time after clock stretching.
Cheers
David
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.
No problem. We have fixed the issue in the following build: Analyzer2Go-2.1.0.28.msi
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/
- You must be logged in to reply to this topic.