Keep getting HAL_Busy for my i2c device

[SabTuna]

Hello everyone 

i've been trying to use FMAMSDXX015WCSC3 force sensor. sensor address 0x28 and whenever i was trying to do IsDeviceReady function, its been always keep getting me HAL_Busy.

HAL_StatusTypeDef status = HAL_I2C_IsDeviceReady(&hi2c2, 0x28 << 1, 10, 2000);

delay(250);

if (status == HAL_OK ){

HAL_Delay(5); //making the status dont be optimized out.

}

And also when i'm using external or internal(in GPIOInitStruct.Pull) pull up resistor that
function giving me a HAL_ERROR. So is my sensor broke or am i doing something wrong?

Down there, there is the my peripherals created by CubeIde.

void HAL_I2C_MspInit(I2C_HandleTypeDef* hi2c)

{

GPIO_InitTypeDef GPIO_InitStruct = {0};

if(hi2c->Instance==I2C2)

{

/* USER CODE BEGIN I2C2_MspInit 0 */

/* USER CODE END I2C2_MspInit 0 */

__HAL_RCC_GPIOB_CLK_ENABLE();

/**I2C2 GPIO Configuration

PB10 ------> I2C2_SCL

PB11 ------> I2C2_SDA

*/

GPIO_InitStruct.Pin = GPIO_PIN_10|GPIO_PIN_11;

GPIO_InitStruct.Mode = GPIO_MODE_AF_OD;

GPIO_InitStruct.Pull = GPIO_NOPULL;

GPIO_InitStruct.Speed = GPIO_SPEED_FREQ_LOW;

GPIO_InitStruct.Alternate = GPIO_AF4_I2C2;

HAL_GPIO_Init(GPIOB, &GPIO_InitStruct);

/* Peripheral clock enable */

__HAL_RCC_I2C2_CLK_ENABLE();

void MX_I2C2_Init(void)

{

/* USER CODE BEGIN I2C2_Init 0 */

/* USER CODE END I2C2_Init 0 */

/* USER CODE BEGIN I2C2_Init 1 */

/* USER CODE END I2C2_Init 1 */

hi2c2.Instance = I2C2;

hi2c2.Init.ClockSpeed = 100000;

hi2c2.Init.DutyCycle = I2C_DUTYCYCLE_2;

hi2c2.Init.OwnAddress1 = 0;

hi2c2.Init.AddressingMode = I2C_ADDRESSINGMODE_7BIT;

hi2c2.Init.DualAddressMode = I2C_DUALADDRESS_DISABLE;

hi2c2.Init.OwnAddress2 = 0;

hi2c2.Init.GeneralCallMode = I2C_GENERALCALL_DISABLE;

hi2c2.Init.NoStretchMode = I2C_NOSTRETCH_DISABLE;

if (HAL_I2C_Init(&hi2c2) != HAL_OK)

{

Error_Handler();

}

/* USER CODE BEGIN I2C2_Init 2 */

/* USER CODE END I2C2_Init 2 */

}

[######]

Is FMAMSDXX015WCSC3 the correct part number for your part? 

Looking at a datasheet:

FM = MicroForce Sensors

A = Compensated / Amplified

M = Mechanical

S = Sphere

D = Sensor Short and Open

XX = Future Placeholder

015 = 15 Newtons

W = Newton

C = Compression

S = SPI

C = Transfer Function

3 = 3.3V

This would suggest its an SPI interface (rather than I2C)?

https://sps.honeywell.com/content/dam/honeywell-edam/sps/common/en-us/industries/healthcare-and-life-sciences/medical-equipment/documents/sps-medical-fma-series.pdf

[David Littell]

Also, don't use the internal pull-ups - use proper external pull-up resistors (10K should be fine).

[SabTuna]

when copying from datasheet i was copied wrong name it is FMAMSDXX015WC2C3 sorry to missleading you. 2 means ı2c 0x28.

[SabTuna]

Well, in the datasheet, it said 1k is enough, and I used a 2.2k resistor. I should change it, I guess. And 10k doesn't work. And when I am using a pull-up resistor, it still gives me a HAL_ERROR. I guess my sensor has been broken. So, are there any other things I should try? It was an expensive sensor, and I don't want to throw it away if I'm not 100% sure it's broken.

[David Littell]

10K is fine for normal applications at 100 kHz.  Post a schematic.  Get a scope on both SCL and SDA.

[Piranha]

...it still gives me a HAL_ERROR. I guess my sensor has been broken. So, are there any other things I should try?

---

A beginner code based on the HAL broken bloatware is not an indicator of hardware flaws or basically anything. You can try learning and developing a decent code.

[######]

As @David Littell suggested you need to go through the "Physical" board level stuff first to satisfy yourself that that is all correct. Some suggestions below:

• Is the schematic design correct?
• Is the PCB design correctly matching the device pinout?
• Is the device soldered correctly (no dry joints or missing solder)?
• Is the device orientation soldered correct so as to match the pins?
• Can you check correct voltages at the correct supply pins of the device?
• Can you see the I2C Clock and / or Data using an oscilloscope or logic analyser?
• Does the I2C clock frequency match expectation?
• Does the I2C Address / Data endianness and format, match expectation?

These little steps may not solve your problem yet, but it builds more confidence on what the problem isn't. 

Note: You may have done these already, but without knowing the answer to these its hard to say if the device is "broken" unless you know that there's a chance it probably is for some reason.