Possible LPUART transmitter issue when using low BRR[15:0] value
Description
The LPUART transmitter bit length sequence is not reset between consecutive bytes, which could result in a jitter that cannot be handled by the receiver device. As a result, depending on the receiver device bit sampling sequence, a desynchronization between the LPUART transmitter and the receiver device may occur resulting in data corruption on the receiver side.
This happens when the ratio between the LPUART kernel clock and the baud rate programmed in the LPUART_BRR register (BRR[15:0]) is not an integer, and is in the three to four range. A typical example is when the 32.768 kHz clock is used as kernel clock and the baud rate is equal to 9600 baud, resulting in a ratio of 3.41.
Workaround
Apply one of the following measures:
- On the transmitter side, increase the ratio between the LPUART kernel clock and the baud rate. To do so:
- Increase the LPUART kernel clock frequency, or
- Decrease the baud rate.
- On the receiver side, generate the baud rate by using a higher frequency and applying oversampling techniques if supported.
SPI
Possible corruption of last-received data depending on CRCSIZE setting
Description
With the CRC calculation disabled (CRCEN = 0), the transfer size bitfield set to a value greater than zero (TSIZE[15:0] > 0), and the length of CRC frame set to less than 8 bits (CRCSIZE[4:0] < 00111), the last data received in the RxFIFO may be corrupted.
Workaround
Keep the CRCSIZE[4:0] bitfield at its default setting (00111) during the data reception if CRCEN = 0 and TSIZE[15:0] > 0.
MODF flag cannot generate interrupt
Description
Mode fault detection results in disabling SPI. With the MODFIE bit of the SPI_IER register set, the mode fault flag (MODF) going high is expected to trigger an interrupt. However, disabling SPI unduly blocks this interrupt request.Workaround
To detect a mode fault event, poll the MODF flag by software.RDY output failure at high serial clock frequency
Description
When acting as slave with RDY alternate function enabled through setting the RDIOM bit of the SPI_CFG2 register, the device may fail to indicate its Not ready status in time through the RDY output signal to suspend communication. This may then lead to data overrun and/or underrun on the device side. The failure occurs when the serial clock frequency exceeds:
- Twice the APB clock frequency, with data sizes from 8 to 15 bits
- Six times the APB clock frequency, with data sizes from 16 to 23 bits
- Fourteen times the APB clock frequency, with data sizes from 24 to 32 bits
Workaround
None.
Master communication suspension fails in autonomous mode
Description
The SPI peripheral is blocked regardless of the completion of the ongoing data frame transaction, and the SUPSF flag is never set, when:
- The master provides a communication triggered in autonomous mode (TRIGEN=1 of the SPI_AUTOCR register), and
- The suspension of the ongoing transaction is applied by setting the CSUSP bit through the smart DMA in Stop mode.
Workaround
None.
Note:
The user software must avoid any master suspension in Stop mode while the master operates in autonomous mode and waits for EOT if TSIZE is greater than 0. If an endless transaction is applied (TSIZE = 0), the suspension is the only way to stop the ongoing transaction. Then to unblock the peripheral, the software must disable SPI then apply the hardware reset. Otherwise, the system cannot proceed to the next transaction.
SPE may not be cleared upon MODF event
Description
The failure described applies to multi-master topology when the device is configured to monitor the SS input signal by hardware (SSM = 0, SSOE = 0 of the SPI_CFG2 register).
If the software sets the SPE (SPI enable) bit of the SPI_CR1 register at the instant of the SS signal transiting to its active logical level, the resulting MODF event duly switches the SPI into slave mode, but it fails to clear the SPE bit and thus disable the SPI.
Note:
The SS active logical level is the one that matches the SSIOP bit of the SPI_CFG2 register.
Workaround
Whenever MODF event fails to clear the SPE bit, do it by software.
SPI slave stalls with masters not providing extra SCK periods upon Not ready signaling
Description
In Stop mode, the device SPI operating as slave with the Ready signaling enabled (the RDIOM of the SPI_CFG2 register set) may stall and never retrieve the Ready state. This occurs when SCK stops immediately after Not ready status.
Note:
STM32 devices supporting the Ready signaling and operating as SPI master provide some extra SCK periods upon detecting Not ready signal, thus allowing the SPI slaves to operate correctly.
Workaround
If in the application, there is an SPI master that stops SCK immediately upon Not ready signal, without providing some extra SCK periods, do not enable the Ready signaling.
Truncation of SPI output signals after EOT event
Description
After an EOT event signaling the end of a non-zero transfer size transaction (TSIZE > 0) upon sampling the last data bit, the software may disable the SPI peripheral. As expected, disabling SPI deactivates the SPI outputs (SCK, MOSI and SS when the SPI operates as a master, MISO when as a slave), by making them float or statically output their by-default levels, according to the AFCNTR bit of the SPI_CFG2 register.
With fast software execution (high PCLK frequency) and slow SPI (low SCK frequency), the SPI disable occurring too fast may result in truncating the SPI output signals. For example, the device operating as a master then generates an asymmetric last SCK pulse (with CPHA = 0), which may prevent the correct last data bit reception by the other node involved in the communication.
Workaround
Apply one of the following measures or their combination:
- Add a delay between the EOT event and SPI disable action.
- Decrease the ratio between PCLK and SCK frequencies.
TIFRE flag wrongly set in slave PCM long frame mode if FIXCH = 1
Description
When FIXCH = 1, the flag TIFRE indicates an error when channel length indicated by WS does not last as expected. In slave PCM long frame mode, TIFRE is wrongly set, indicating a frame error even if it did not occur.
This issue occurs when all the following conditions are met:
- I2SMOD[1:0] = 1 (I2S/PCM mode) in the SPI_I2SCFGR register
- I2SCFG[2:0] = 000 or 001 or 100 (slave modes) in the SPI_I2SCFGR register
- I2SSTD[1:0] = 11 (PCM) and PCMSYNC=1 (PCM long) in the SPI_I2SCFGR register
- FIXCH[1:0] = 1 (channel length given by CHLEN) in the SPI_I2SCFGR register
Workaround
None. Ignore the TIFRE flag.
TIFRE flag never set in slave PCM/I2S mode if FIXCH = 0
Description
When FIXCH = 0, the TIFRE flag in the SPI_SR register is set to indicate a frame error if a new frame synchronization is received while the shift-in or shift-out of the previous data is not complete (early frame error). Instead, this flag is not set, and no frame error is detected.
This issue occurs when all the following conditions are met:
- I2SMOD[1:0] = 1 (I2S/PCM mode) in the SPI_I2SCFGR register
- I2SCFG[2:0] = 000 or 001 or 100 (slave modes) in the SPI_I2SCFGR register
- FIXCH[1:0] = 0 (CHLEN different from 16 or 32) in the SPI_I2SCFGR register
Workaround
None. Ignore the TIFRE flag.