cancel
Showing results for 
Search instead for 
Did you mean: 

I2C Not Working

Jonathan-Halltech
Associate II

Hello,

I am trying to setup an external ADC/DAC module with an STM32H7 microcontroller. 

I2C Slave - EVAL-AD5593R-PMDZ

I2C Master - STM32H757XIH6 on STM32 Embedded Display by Riverdi

I am struggling to get the very basics of communication to work as I cannot get a return of HAL_OK.

The slave address for the AD5593R should be 0b0010001 as the A0 bit for the IC on the module is always connected to Vcc according to the schematic for the board.

The I2C2 peripheral is setup by STM32IDE and the timing is set for 400 kHz which the AD5593R can work on.

Any thoughts on what may be my issue would be extremely helpful!!! Thanks a lot.

 

What I have tried:

-Swapping slave address bit A0 to 0

-Removing left shift for slave address

-Adding a 0 for write command to the slave address

-Using HAL I2C Master Transmit

 

Hardware Connections:

STM32 Pin 2 +3.3V -> AD5593R Pin 6 Vcc

STM32 Pin 6 GND -> AD5593R Pin 5 GND

STM32 Pin 34 I2C2_SDA -> AD5593R Pin 4 SDA

STM32 Pin 36 I2C2_SCL -> AD5593R Pin 3 SCL

 

Main Code:

static const uint8_t AD5593_ADDR = 0b0010001 << 1;                    // AD5593 address, left shift 1
HAL_StatusTypeDef ret;

ret = HAL_I2C_IsDeviceReady(&hi2c2, AD5593_ADDR, 4, 1000);

 

I2C Initialize:

/* I2C2 init function */
void MX_I2C2_Init(void)
{
hi2c2.Instance = I2C2;
hi2c2.Init.Timing = 0x00501D55;
hi2c2.Init.OwnAddress1 = 0;
hi2c2.Init.AddressingMode = I2C_ADDRESSINGMODE_7BIT;
hi2c2.Init.DualAddressMode = I2C_DUALADDRESS_DISABLE;
hi2c2.Init.OwnAddress2 = 0;
hi2c2.Init.OwnAddress2Masks = I2C_OA2_NOMASK;
hi2c2.Init.GeneralCallMode = I2C_GENERALCALL_DISABLE;
hi2c2.Init.NoStretchMode = I2C_NOSTRETCH_DISABLE;
if (HAL_I2C_Init(&hi2c2) != HAL_OK)
{
Error_Handler();
}

HAL_I2CEx_EnableFastModePlus(I2C_FASTMODEPLUS_I2C1);
}

15 REPLIES 15

@Jonathan-Halltech wrote:

 I also tried using the other I2C channel and pins (I2C4) and they also show no output on the oscilloscope. 


Did you have pullups present when you tested?

You wouldn't see anything without pullups ...

Can you put a break point in here to be sure that it is called? Even though it overrides the weak function, maybe it's not being called?

void HAL_I2C_MspInit(I2C_HandleTypeDef* i2cHandle)
{
...

  else if(i2cHandle->Instance==I2C2)
  {
  /* USER CODE BEGIN I2C2_MspInit 0 */

  /* USER CODE END I2C2_MspInit 0 */

  /** Initializes the peripherals clock
  */
    PeriphClkInitStruct.PeriphClockSelection = RCC_PERIPHCLK_I2C2; **** Put break point on this line ****
    PeriphClkInitStruct.I2c123ClockSelection = RCC_I2C123CLKSOURCE_D2PCLK1;
    if (HAL_RCCEx_PeriphCLKConfig(&PeriphClkInitStruct) != HAL_OK)
    {
      Error_Handler();
    }

 

If you find my answers useful, click the accept button so that way others can see the solution.

Yes pullups were present. Everything was connected as mentioned originally, the EVAL-AD5593R-PMDZ with the pull up resistors has probe test points which I connected the oscilloscope to. Thanks for mentioning. 


@Jonathan-Halltech wrote:

Yes pullups were present. Everything was connected as mentioned originally, the EVAL-AD5593R-PMDZ with the pull up resistors has probe test points which I connected the oscilloscope to. Thanks for mentioning. 


Though it doesn't explain why you don't see data activity, the 100k pull-up is too high especially for fast mode.  At least that is what TouchGFX default I2C speed is generating. You should be in the neighborhood of 4.7k. 

If you find my answers useful, click the accept button so that way others can see the solution.
Jonathan-Halltech
Associate II

Thank you everyone for the assistance. The Riverdi support noted that the schematic for the AD5593R board shows the pull up resistor circuit but there is a "DNI" written beside the two resistors, meaning do not install. I added pull up resistors and everything is working as expected. I should have tried this from the beginning, unfortunately I was not familiar with DNI markings. Thanks again. 

Glad you found it!

 


@Jonathan-Halltech wrote:

 I should have tried this from the beginning, . 


Checking with an oscilloscope would have revealed it ...