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.
Remove the direct use of the microsecond and low power ticker from
the tests. This enforces that sleep mode is properly locked when
using timers. Furthermore, this prepares the codebase for new ticker
changes which allow differing clock frequencies and timer bit widths.
Release the deep sleep lock when running instances of the Timer class
are deleted. This ensures that deep sleep locks are properly released
by the Timer class.
When the RTOS is present and the tickless mode is not implemented, it is
expected that the next tick issued by the Systick timer will wake up the MCU.
However nothing prevents an implementation of the ARM architecture to gate the
systick clock signal upon sleep entry.
Therefore on those targets sleep shall be prohibited if the RTOS is present and the
tickless mode is not implemented.
To ease life of porters , a new option has been added in the device add list:
STCLK_OF_DURING_SLEEP. This option expose that the target turn of the systick
clock during sleep.
Targets which exhibit such behavior shall add this define in their device_has list.
Quoting linker preprocessor command, if path contains parentheses. Using
relative path to shorten list of included directories. Using Eclipse
variables to get path to preprocessor.
Sometimes Sw4STM32 exporter receives wrong linker script file. Because build
directories cannot be excluded from scanned resources, ld files are removed.
STM32F439xI-family MD5, SHA1 and SHA256 hardware acceleration
occasionally produces incorrect output (#5079).
Don't enable MD5, SHA1 and SHA256 HW acceleration on STM32F439xI-family
targets by default until issue #5079 is fixed.
The osKernelGetTickCount() is the only function to get kernel tick information,
however it's not allowed to access in ISR.
It's already enabled in API v2.1.1.
UARTSerial inherits both FileHandle::readable() [public] and
SerialBase::readable() [private], so calling readable() on a UARTSerial
object produces an ambiguous member error.
Add using declarations to direct towards the FileHandle versions of
readable and writable.
There's currently no ambiguity for writable, as SerialBase uses the
spelling 'writeable', but add a using directive for that anyway, in case
SerialBase gains 'writable' later.