I2C SDA line stuck low after requestFrom with more than 1 byte - No I2C Stop sequence generated

[yec23]

Describe the bug
I2C SDA line stuck low after requestFrom with more than 1 byte. Master seems to not generate the I2C Stop sequence.
Same result in normal or fast mode.
Working ok when requesting 1 byte
Same hardware and code run well when compiled with Roger Clark environment on Arduino IDE 1.8 Linux.

To Reproduce

• Wire.requestFrom with two bytes or more return ok but SDA remains low. Adding stop parameter (true) has same behaviour (argument defaulted to true)
• I2C Registers after begin() and before requestFrom() call:
  CR1: 1
  CR2: 0x24
  SR1: 0
  SR2: 0
  After requestFrom() call:
  CR1: 0xA01 => POS and STOP set
  CR2: 0x424 => ITBUFEN set
  SR1: 0x240 => ARLO and RxNE set
  SR2: 2 => BUSY set
• Successive requestFrom then end in error.
• Only a end() and begin() resume I2C state.

Steps to reproduce the behaviour:
see code attached
Sourcecode.txt

Screenshots
With Arduino Core STM32: no I2C STOP generated

With Roger Clark, I2C STOP generated

Desktop (please complete the following information):

• OS: Windows 10
• Arduino IDE version: 2.1.0
• STM32 core version: 2.6.0
• Tools menu settings if not the default: USB support: CDC (generic serial supersede U(S)Art), U(S)ART support Enable (generic serial)
• Upload method: SWD

Board (please complete the following information):

• Name: Blue PillF103CB 128k
• Extra hardware used if any: MPU-6050 slave

Additional context
First version of the project was implemented with Roger Clarck STM32 environment. Project is being migrated to Arduino Core STM32 before implementing new features.

[fpistm]

Hi @yec23
Thanks for this detailed report. Unfortunately, we do not have the MPU-6050 slave so we can't reproduce.
Could you provide an example without usage of external device?

Note: I guess you have PU resistors on each I2C lines?

[yec23]

Hi and thank you for your answer.

Do you expect the Wire library example "master_reader_writer" ? Tell me.
I would be surprised it does not work as it comes with the Core and was, I guess tested Ok.

I don't have external resistors. Setup proved to be fine when compiled with RC so I concluded I did not have to investigate further this possibility. Isn’t it a good enough prove that the issue is not coming from that area?

Thanks again for your help.

[fpistm]

Isn’t it a good enough prove that the issue is not coming from that area?

Not necessarily as RC core could implement workaround and also probably set pins with PU. So please ensure to have PU on each I2C lines.

[yec23]

Can I provide you with GPIOB->CRH: 0x4444DD44,
Mode10: 01b => Output mode, max speed 10 MHz
CNF10 : 11b => Alternate function output Open-drain
Mode11: 01b => Output mode, max speed 10 MHz
CNF11 : 11b => Alternate function output Open-drain

[fpistm]

Is it for RC or this core?

[fpistm]

You can add this to your sketch to enable internal PU (https://github.com/stm32duino/Arduino_Core_STM32/wiki/Custom-definitions#custom-pinmap-array):

const PinMap PinMap_I2C_SDA[] = {
  {PB_11, I2C2, STM_PIN_DATA(STM_MODE_AF_OD, GPIO_PULLUP, AFIO_NONE)},
  {NC,    NP,   0}
};

const PinMap PinMap_I2C_SCL[] = {
  {PB_10, I2C2, STM_PIN_DATA(STM_MODE_AF_OD, GPIO_PULLUP, AFIO_NONE)},
  {NC,    NP,   0}
};

[yec23]

Hi, I've added the two variables declaration. Result is the same: SDA low after requestFrom call.
GPIOB->CRH: changed to 0x44449944: CNF 10 and 11 = 10b. MODE remaining 01b

[yec23]

GPIO CRH provided were for the STM32 Core.
RC compilation uses GPIO CRH 0x4443FF44

• Mode 10/11: 11b => Output mode, max speed 50 MHz
• CNF10/11 : 11b => Alternate function output Open-drain
  STM Reference manual (RM008 9.1.11 GPIO configurations for device peripherals, Table 27. I2C) says both lines should be configured “Alternate function open drain”.

To answer “Note: I guess you have PU resistors on each I2C lines?”
I added 2K Pull-Up resistors on each I2C line. Results remain the same i.e., no STOP sequence but still hese 8 SDA HIGH before line goes down.

Registers are having same values
CR1: A01
CR2: 424
SR1: 240
SR2: 2

I think I have answered all your points. Tell me if can investigate others. Thank you again for your insights.

[fpistm]

I have no more insight. Or maybe related to stretch feature anyway as I can not reproduce I could not help more.

/Edit:
1: 2k is maybe too low, usually we used 4.7K.
2: I've updated my comment to change STM_MODE_AF_OD to STM_MODE_AF_OD, if you can test?

[yec23]

1: Put 4.7K resitors in place of 2K
2: Change code to use STM_MODE_AF_OD
Still facing the issue.

Could you clarify following point : when in Master Receiver mode, STM32F103xx RM008 describes two methods
Do you confirm the Core uses Method 2. i.e. "Interruption Mode" ? Is there a way to use Method 1 i.e. "Blocking mode" ?

[brightproject]

Just the other day I updated the core STMicroelectronics v.2.6.0, and the MPU9250 stopped working.

[fpistm]

I got an MPU 6050 and test your code and see no issue.
I've also tested with https://github.com/electroniccats/mpu6050 and it works as expected.