STM32F4 Discovery issue with I2C addresses of CS43L22 audio DAC

[maciej_333]

I want to interconnect STM32F407 microcontroller (on the STM32F4 Discovery board) with CS43L22 audio DAC from the same board and external TV tuner R820T but on the same I2C bus. The R820T works correct when RESET line of the CS43L22 is tied low. When I turned RESET line to high in my code and added initialization code for CS43L22 (including I2S) it works fine but R820T not. Here comes schematic diagram. The CS43L22 and obviously R820T are connected to I2C1 PB9 (SDA) and PB6 (SCL):

The A0 line is connected to ground so I2C address is 0x94 and it's correct. According to the R820T datasheet it has 0x34 address:

So what's the issue? I faced addresses conflict. I checked my code and hardware with oscilloscope and logic analyzer. It's also everything perfect except something extremely strange with CS43L22. It shouldn't be something like that but CS43L22 respond to both addresses 0x94 and 0x34. I disconnected my board with R820T from the Discover Board and it's really like that. I scanned I2C bus with simple code Link :

UART_printf("Scanning I2C bus:\r\n");
  	HAL_StatusTypeDef result;
   	uint8_t i;
   	for (i=1; i<128; i++)
   	{
   	   //the HAL wants a left aligned i2c address
   	   //&hi2c1 is the handle
   	   //(uint16_t)(i<<1) is the i2c address left aligned
   	   //retries 2
   	   //timeout 2
   	  result = HAL_I2C_IsDeviceReady(&hi2c1, (uint16_t)(i<<1), 2, 2);
   	  if (result != HAL_OK) // HAL_ERROR or HAL_BUSY or HAL_TIMEOUT
   	  {
   		UART_printf("."); // No ACK received at that address
   	  }
   	  if (result == HAL_OK)
   	  {
   		UART_printf("0x%X", i); // Received an ACK at that address
   	  }
   	}
   	UART_printf("\r\n");

Here comes the result with CS43L22 RESET line high:

So I have 0x1A and 0x4A. After left bit shift it's 0x34 and 0x94. Please remember R820T was disconnected. I tested it on the pure Discovery Board without additional hardware. The result with CS43L22 RESET line low:

I don't have any I2C devices and It's exactly as I expected. Here comes proper reading sequence of R820T from logic analyzer with CS43L22 RESET line low:

It's everything correct and no addresses conflict. The same experiment but with CS43L22 RESET line high:

As you can see I got all zeros because CS43L22 tied SDA line to ground. I have large SCL frequency because CS43L22 requires something like that (roughly 115 kHz or higher):

It's one of the most strange issue I've ever seen. The CS32L22 datasheet doesn't mention about it. I know that the only possible solution is connect R820T to another I2C bus and I can do that. Someone can test it on the same board? I mean only scan I2C addresses.

[Karl Yamashita]

I2C slave address is 0x34, not 0x94. What the HAL driver wants is a left shifted I2C slave address value, so the "argument" passed is 0x94. Saying 0x94 is an I2C address would be incorrect usage as I2C uses 7bit address, in most cases, so you can't have a slave address greater than 0x7F.

Valid I2C address are from 0x08 to 0x78, where other values are reserved.

Back to "CS43L22 respond to both addresses 0x94 and 0x34"

If you are passing an argument 0x94 or 0x34 and the CS43L22 responds, then does it have a secondary slave address that responds to 0x1A? And when you say "respond" do you mean ACK?

[TDK]

Super weird.

Probably a question for Cirrus Logic then. But on a discontinued product, not sure how much they will care.

[maciej_333]

@TDK Yeah it's super weird but STM32F4 Discovery Board is relatively old product. Why no one has ever faced such issue? Maybe I send something to Cirrus Logic about it. It's look like silicone bug but they don't have something like Silicone Errata.

@Karl YamashitaSorry English isn't my first language and I didn't express my issues clarify enough. I have respond and as you guessed ACK from CS43L22 on the two addresses: 0x1A and 0x4A. As you guessed it has secondary slave address that is exactly the same as slave address of the R820T. I know that I2C address space is 7-bit. I obviously use 0x1A and 0x4A but to the HAL driver I put it left bit shifted as it's required. In the R820T datasheet they have it left bit shifted already.

My goal is simple SDR receiver based on the R820T. I designed simple analog IF amplifier and I estimated calculation time in STM32F407. It should be possible to do that. Here comes IF schematic diagram:

[AScha.3]

So try setting AD0 on the CS32L22 hi, then address value  is 0x96  .

And no more response to the R820T addressing .

[maciej_333]

@AScha.3I took photo of the CS43L22 on my Discovery Board:

I can cut path from AD0 and solder it via piece of wire to +3V but I don't want to rework on the PCB. It's obvious that it change 0x4A address but I don't know what would happen with secondary address 0x1A that is the same like R820T address.

[AScha.3]

>but I don't know what would happen with secondary address 0x1A

So try it - then you know. :)

IF your CS43L22 has a problem with its address decoder, it should change to 0x36 .

btw

Strange for this old CS43L22 , that nobody than you discovered its faulty response to 0x1A .

see:   https://github.com/andysworkshop/stm32plus/blob/master/examples/cs43l22_beep/cs43l22_beep.cpp

or

Just use other I2C for your R820T .

[maciej_333]

@AScha.3  I can change AD0 line state but my project would be difficult to replicate for someone other. I'll use other I2C for R820T.

[mattewwade06]

I’ve run into a similar issue before when working with the CS43L22 on the STM32F4 Discovery board. One thing to double-check is whether you're using the correct 7-bit I2C address. The datasheet lists 0x94 as the 8-bit address, which translates to 0x4A in 7-bit format (after shifting right by 1). Using 0x94 directly in STM32 HAL functions often causes communication problems.

Also, make sure your I2C peripheral is properly initialized and the clock speed matches the spec for the CS43L22. A logic analyzer or oscilloscope can be very helpful to confirm whether the ACK is being received from the device.

[maciej_333]

It's not like that. I checked everything with logic analyzer and oscilloscope and it's obvious that CS43L22 respond to both addresses and it's everything explained in my first post. I connected R820 to other I2C bus.

The datasheet address 0x94 from CS43L22's datasheet's is left shifted. It means that I have to use 0x94 with HAL drivers just like that:

#define DAC_I2C_ADDR 			0x94

//...

static void write_register(uint8_t reg, uint8_t *data)
{
	iData[0] = reg;
	iData[1] = data[0];

	if (HAL_I2C_Master_Transmit(&i2cx, DAC_I2C_ADDR, iData, 2, 100) != HAL_OK)
	{
		CS43_TIMEOUT_UserCallback();
	}
}

Here comes write sequence from datasheet:

Generally speaking it's one of the most strange hardware issues I've ever faced.