With tickless mechanism hsem can be used for quite a long time
(time to set up PLL clock).
Also, if hsem is held to long, then this is not the current core which is faulty,
but probably the other (the one which hold the HSEM)
Add 2 targets for DISCO_H747I dualcore:
* DISCO_H747I -> for CM7 core
* DISCO_H747I_CM4 -> for CM4 core
Current restrictions:
* TICKLESS deactivated
* DeepSleep not supported (DeepSleep wrapped to sleep)
Warning: use of the same IP (example I2C1) by both core at the same time is not prevented,
but is strongly not recommended.
Some Hardware Semaphore are use for common IP, to manage concurrent access by both cores: Flash, GPIO, RCC.
Warning: Drag and drop of binary to DISCO_H747I will flash CM7.
In order to flash CM4, one can use STM32 CubeProgrammer tool.
Keep former behaviour for I2C V1.
For I2C V2:
Use only I2C_FIRST_FRAME, I2C_FIRST_AND_LAST_FRAME and I2C_LAST_FRAME,
thus we avoid using reload bit.
Reload suppose the next frame would be in the same direction,
but we have no guarranty about this. So we cannot use reload bit.
Note: in case of 2 consecutive I2C_FIRST_FRAME,
a restart is automatically generated only if there is direction change in the direction.
Need to ensure the transmission has been started before sending a STOP condition.
Issue found on the NUCLEO_H743ZI due certainly to the high-speed clock used.
But this is normally needed also on all STM32 devices using the I2C peripheral version 2.
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.
Some I2C devices require specific zero length read/write sequences which
the HAL_I2C_IsDeviceReady() redirect interferes with. After Removing
these redirects, it was confirmed that zero length reads and writes
would both still work correctly for detecting presence/absence of an
I2C device on a bus.
If I2C slave support is included, then the I2C error handler would
always reset the I2C address, resulting in incorrectly changing the
I2C state to listen for a controller configured as I2C master. This
change conditionalizes the address setting to only occur if the
controller was in slave mode when the error occurred.
The default pin mode shall be set as part of the pinamp_pinout, and
as defined in tables of PeripheralPins.c, but this is currently
over-written by a call to pin_mode(pin, PullNone); from
mbed_pinmap_common.c, so we need a set the mode again here, including
OpenDrain config as needed for I2C.
this I2C IP is meant for automatic STOP, based on programmed number
of bytes to be sent or receivede, not a user triggered STOP.
So the state machiine needs to be reset in case we use this I2C mbed
unitary API (start / byte_write / byte_read / stop).
Following HAL update, this is needed to use the I2C API function
rather than previously used MACRO.
An assert would fail at compilation time otherwise.
STM32 supported targets have 2 possible versions of I2C.
This patch makes the start / stop / read and write byte work ok for IP V2.
This was not working before and does not seem to be widely used.
In case the user applicaiton makes a mixed usage of unitary function
(start, stop, byte write & read) with SYNC operation (write and read of
data buffers with start and stop management), we need to reset the
STM32 HAL state as it is by-passed by a direct call to STOP
The hz value is used to compute timeouts,
and timeout are used in reset function, so the parameter needs to be
initialized to its default value before being used.
So make the assert to cover all possible values
Also assert applies only for I2C_IP_VERSION_V2.
Also in case of I2C_IP_VERSION_V1, the HAL makes the proper
checks and can dynamically scale the frequency in case of
intermediate value.
Since most of the code in i2c_api.c is now relying on STM32 HAL, there
is now a possibility to make a common usage of this code accross families.
The IP version definition is introduced per family, to allow a switch of
functionnalities, especially the frequency management which differs.
BTw, we fix the F0 frequency settings at the same time.
F1 is managed for now as an exception as the HAL API for sequential transmit
/receive is not yet available (coming soon)
Martin Kojtal
Przemyslaw Stekiel
Alexandre Bourdiol
jeromecoutant
Michael Coulter
Russ Butler
bcostm
Laurent MEUNIER
Bradley Scott
Christopher Haster
Sam Grove
Anna Bridge