STM32L4xx I2C waveform is something strange.

[ihbaek.wcabaid]

figure-1 I2C waveform with STM32L433rc-p Nucleo board.

When I try to use STM32L433RC-P Nucleo's I2C for communicating with AT24C01 I2C EEPROM, two strange waveform occurred. This strange waveform is not occurred from another model STM32 MCU.(example. STM32G0xx Nucleo board. See below figure.2.)
1. It makes strange low level spike.
2. It makes strange and very narrow I2C waveform compared to other  STM32 MCU devices.

I used HAL function "HAL_I2C_Mem_Read(&hi2c1, 0xA0, 0x00, 1, &dat, 1, 1000);" for I2C commucating with AT24C01 device.  

I didn't experienced any I2C communation error with that strange waveform, but I want to confirmed this strange waveform don't affected I2C norminal operation.

Is these strange waveforms normal case?

figure.2 - I2C waveform from STM32G0B1RE Nucleo board.

[waclawek.jan]

The spikes may be consequence of crosstalk (too long SDA/SCL close to each other) or improper ground/return arrangement. I hope you are not attempting to use jumper wires and solderless breadboards. 

Besides reviewing hardware try decreasing the SCLs OSPEEDR setting.

[EDIT] see my next post below [/EDIT]

JW

[Andrew Neil]

You haven't said what pins you're using for I2C.

Show a schematic of your setup.

Some good, clear photos may also help.

https://community.st.com/t5/community-guidelines/how-to-write-your-question-to-maximize-your-chances-to-find-a/ta-p/575228

Have you checked the board's User Manual and/or schematics to see if there's anything else on those pins?

[ihbaek.wcabaid]

When I changed the pins from PB7/PB8 to PB6/PB9, nothing changed. It makes same waveform. So, I guess it's not port electric characteristic problem.

[Part Number] : I am using two devices of STM32L4xx. one part number is STM32L433RCT6P, mounted on Nucleo L433RC-P devices, connected to AT24C01.  another number is STM32L431RBT, mounted on our own PCB, connected to M24C04 I2C EEPROM.
[Environment] : I used CubeIDE 1.14.0 and CubeIDE 1.10.0. No difference behavior exist between two. I already checked.
[How to reproduce]

1. connect Nucleo L433RC-P board to AT24Cxx test board with jumper wire.

- You can buy AT24Cxx test board from this site. https://www.waveshare.com/at24cxx-eeprom-board.htm

2. make CubeIDE project. Import below code. and run.

  while (1)
  {
    uint8_t dat;
    /* USER CODE END WHILE */

    /* USER CODE BEGIN 3 */
    HAL_I2C_Mem_Read(&hi2c1, 0xA0, 0x00, 1, &dat, 1, 1000);
    HAL_Delay(1000);
  }

3. probe scope and see waveform.

I added additional detailed waveform below.

[ihbaek.wcabaid]

I have two device for STM32L4xx product.

One is Nucleo test board. another is our real PCB soldered product.
Both produce makes same waveform. So, I think HW/pattern problem is not choice.  

[waclawek.jan]

I realized that this is a normal waveform and depends on particular circumstances such as clock speed, slave's speed etc.

Thing is, that I2C shifts out (changes output) SDA at falling edge of SCL and samples (shifts in, reads) at "rising" edge. More precisely, during the SCL high period. Quoting from the I2C spec: "The data on the SDA line must be stable during the HIGH period of the clock." During SCL low, any changes are allowed.

In this case, the first, shorter peak happens just after the 8th data bit, i.e. master (in modern I2C parlance, "controller"; here: STM32) releases SDA and it succeeds to rise high enough to be noticed when the slave ("target", here: EEPROM) pulls it down to signal ACK. And the next, longer pulse, is after slave releases ACK upon the next shift clock edge, and before STM32 pulls SDA down because of the MSB of next byte is 0.

JW

[ihbaek.wcabaid]

Thanks for your answer.

In addition, Is it any possibility of spike waveform or narrow waveform shifted to forward? So, Is it possible the waveform overrapped to SCL trailing edge and makes some data corruption?

I guess this possibility is zero. But my customer argued It is necessary to confirm zero possibility.

[waclawek.jan]

Yes, there is a possibility that SDA edges will cause spikes on SCL (e.g. due to capacitive coupling, or due to inadequate ground arrangements). So the possibility for that is not zero.

However, there are several things which mitigate this - to certain extent:

- as SDA must not change during SCL high, SDA changes occur when SCL is low, i.e. when SCL is actively pulled down thus SCL is low impedance at that time (exceptions are the START and STOP conditions)

- you as the designer should use an adequately "strong" pullup on SDA/SCL to ensure adequately low impedance in the high state, depending on tracks capacitance and mutual capacitance; also, the ground arrangement should be adequate for given signals

- I2C drivers should have controlled impedance, i.e. they should have (in STM32, you should choose adequate GPIO_OSPEEDR setting)

- I2C receivers should have implemented forms of noise rejection, see analog and digital filter in STM32 I2C, and also the timing settings should reflect the bus setup (RC constants) so that e.g. SDA edges occur when SCL is certainly low. Note, that requirement for noise filtering is part of the I2C specification (although to certain extent optional, or as a recommendation), and external I2C devices implement it in different ways, see datasheets of those devices.

I2C is a tricky bus in that it requires a certain amount of understanding of all the involved mechanisms and their limitations, and design the circuitry and its layout accordingly. What you've done with observation of the bus using oscilloscope is one of the ways to confirm your design is OK in this regard - e.g. the small spike at SCL in the middle of the last picture confirms that the coupling from SDA to SCL is small (compared to the decision level).

JW