STM: I2C: Configure pins in OpenDrainNoPull by default (no pullup)

[LMESTM]

Description

As reported by MBED user Fran6Jack:
I2C bus are usually 5V tolerant on all STM32 processor.
If an external device on the I2C bus requires 5V operation,
we usually acheive it by using 5V external pull-ups on the bus.
Since signaling uses open-drain output on I2C for both signal SCL and SDA
any 5V tolerant MCU will work on a 5V I2C bus. Having pull-up activated on a 5V externally pull bus, cause the pin to clamp on the STM32 die diode and could damage the IC (There is a note in STM32 datasheet specifying this issue).
It is understood by all the community that I2C bus should always be
externally pulled by physical resistor. I2C initialization should then
be ALWAYS OpenDrainNoPull by default.

Up to now, this I2C driver was setting pull up by default as it helps
basic testing, like 1 master and 1 slave, conencted with 2 wires without
any external pull ups. This will not work anymore after this commit and
applications tests or examples needs to be modified to explicitely
configure pull ups ... But it is safer to follow reference manual
guidelines.

Notes:
This is a fix to #5102

Status

READY

Question / open point

After this change, any test or example that was working when simply plugging 2 wires between SDA and SCL pins of 2 boards will not work anymore. There is a need to add external pul-ups - is this fullay acceptable for everyone ?

If not, there is a need for introduction of a new mode interface in I2C class.

Tests

+-------------------+---------------+---------------+--------+--------------------+-------------+
| target            | platform_name | test suite    | result | elapsed_time (sec) | copy_method |
+-------------------+---------------+---------------+--------+--------------------+-------------+
| NUCLEO_F091RC-ARM | NUCLEO_F091RC | tests-api-i2c | OK     | 175.34             | default     |
| NUCLEO_F103RB-ARM | NUCLEO_F103RB | tests-api-i2c | OK     | 176.95             | default     |
| NUCLEO_F207ZG-ARM | NUCLEO_F207ZG | tests-api-i2c | OK     | 175.23             | default     |
| NUCLEO_F303ZE-ARM | NUCLEO_F303ZE | tests-api-i2c | OK     | 174.97             | default     |
| NUCLEO_F446RE-ARM | NUCLEO_F446RE | tests-api-i2c | OK     | 174.59             | default     |
| NUCLEO_F767ZI-ARM | NUCLEO_F767ZI | tests-api-i2c | OK     | 173.24             | default     |
| NUCLEO_L073RZ-ARM | NUCLEO_L073RZ | tests-api-i2c | OK     | 178.29             | default     |
| NUCLEO_L152RE-ARM | NUCLEO_L152RE | tests-api-i2c | OK     | 175.03             | default     |
| NUCLEO_L476RG-ARM | NUCLEO_L476RG | tests-api-i2c | OK     | 175.28             | default     |
+-------------------+---------------+---------------+--------+--------------------+-------------+
mbedgt: test suite results: 9 OK

[LMESTM]

@Fran6Jack
@0xc0170

[betzw]

@LMESTM, do you see any issues with this PR for expansion board drivers?

cc @nikapov-ST

[LMESTM]

@betzw No I don't think this would create any side effects with expansion boards as I'm pretty confident that they all include the required pull-ups resistors. The SW side is not impacted at all.

[0xc0170]

cc @bulislaw @c1728p9 @deepikabhavnani

[bulislaw]

I think that's changing how the I2C class behaves on ST boards. That should be probably in minor release with a reference in the release notes. @sg-

Also the chagnes to I2C class should be looked at platform team @senthilr

[theotherjimmy]

/morph test

[mbed-bot]

Result: ABORTED

Your command has finished executing! Here's what you wrote!

/morph test

[theotherjimmy]

/morph test

[mbed-bot]

Result: SUCCESS

Your command has finished executing! Here's what you wrote!

/morph test

Output

mbed Build Number: 1535

All builds and test passed!