STM8S007xx STM8S20xxx Errata sheet - STMicroelectronics€¦ · 2 Silicon limitations 2.1 Core limitations 2.1.1 Activation level (AL) bit not functional in Halt mode Description

October 2019 ES036 Rev 8 1/26

1

STM8S007xx STM8S20xxxErrata sheet

STM8S007xx and STM8S20xxx device limitations

Silicon identification

This errata sheet applies to revisions X, Y/6, V, W/7 and 1 of the STMicroelectronics STM8S007xx and STM8S20xxx products.

A full list of part numbers is shown in Table 1.

The products can be identified as shown in Table 2:

• By the revision code marked below the sales type on the device package

• By the last three digits of the Internal sales type printed on the box label

Table 1. Device summary

Reference Part number

STM8S007xx STM8S007C8

STM8S207xx

STM8S207MB, STM8S207M8, STM8S207RB, STM8S207R8, STM8S207R6, STM8S207CB, STM8S207C8, STM8S207C6, STM8S207SB, STM8S207S8, STM8S207S6, STM8S207K8, STM8S207K6

STM8S208xxSTM8S208MB, STM8S208RB, STM8S208R8, STM8S208R6, STM8S208CB, STM8S208C8, STM8S208C6, STM8S208SB, STM8S208S8, STM8S208S6

Table 2. Device identification

Sales type Revision code(1) marked on device

1. Refer to product datasheet for details on how to identify the revision code on the different packages.

STM8S007xx V, W/7, 1

STM8S207xxX, Y/6, V, W/7, 1

STM8S208xx

www.st.com

http://www.st.com

Contents STM8S007xx STM8S20xxx

2/26 ES036 Rev 8

Contents

1 Product evolution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2 Silicon limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.1 Core limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.1.1 Activation level (AL) bit not functional in Halt mode . . . . . . . . . . . . . . . . . 8

2.1.2 JRIL and JRIH instructions not available . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.1.3 Main CPU execution is not resumed after an ISR resets the AL bit . . . . 8

2.1.4 Unexpected DIV/DIVW instruction result in ISR . . . . . . . . . . . . . . . . . . . 9

2.1.5 Interrupt service routine (ISR) executed with priority of main process . . 9

2.2 System limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2.2.1 HSI RC oscillator cannot be switched off in Run mode . . . . . . . . . . . . . 10

2.2.2 LSI oscillator remains on in Active-halt mode when the AWU unit uses the HSE as input clock . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2.2.3 Failure in CAN communication during bootloader . . . . . . . . . . . . . . . . . 10

2.2.4 RAM modified after reset by embedded bootloader . . . . . . . . . . . . . . . 10

2.2.5 Flash / EEPROM memory is read incorrectly after wakeup from power down mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

2.2.6 VDD rise-time rate for 100mV < VDD < 1V . . . . . . . . . . . . . . . . . . . . . . . 12

2.3 Timer peripheral limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

2.3.1 Corruption of read sequence for the 16-bit counter registers . . . . . . . . 12

2.4 UART peripheral limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2.4.1 PE testing issue in UART mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2.4.2 LIN mode: LIN header error when automatic resynchronization is enabled . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2.4.3 LIN mode: framing error with data byte 0x00 . . . . . . . . . . . . . . . . . . . . . 14

2.4.4 LIN mode: framing error when receiving an identifier (ID) . . . . . . . . . . . 14

2.4.5 LIN mode: parity error when receiving an identifier (ID) . . . . . . . . . . . . 14

2.4.6 LIN mode: OR flag not correctly set in LIN master mode . . . . . . . . . . . 14

2.5 I2C peripheral limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

2.5.1 I2C event management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

2.5.2 Corrupted last received data in I2C Master Receiver mode . . . . . . . . . 15

2.5.3 Wrong behavior of I2C peripheral in Master mode after misplaced STOP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

2.5.4 Violation of I2C “setup time for repeated START condition” parameter . 17

ES036 Rev 8 3/26

STM8S007xx STM8S20xxx Contents

3

2.5.5 In I2C slave “NOSTRETCH” mode, underrun errors may not be detected and may generate bus errors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

2.5.6 I2C pulse missed . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

2.6 SPI peripheral limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

2.6.1 Last bit sent is too short if the SPI is disabled during communication . . 19

2.6.2 Busy flag is not reliable when the SPI is a master simplex receiver . . . 19

2.7 beCAN peripheral limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

2.7.1 beCAN transmission error when Sleep mode is entered during transmission or reception . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

2.7.2 beCAN woken up from Sleep mode with automatic wakeup interrupt . . 20

2.7.3 beCAN time triggered communication mode not supported . . . . . . . . . 20

2.7.4 beCAN transmitted data corruption . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

2.7.5 beCAN read error in slow mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

2.7.6 Write in beCAN paged registers ignored . . . . . . . . . . . . . . . . . . . . . . . . 21

2.8 Miscellaneous . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

2.8.1 PWM output available on two different ports (PC4 and PD7) when TIM1_CH4 user option is set . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

3 Revision history . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

List of tables STM8S007xx STM8S20xxx

4/26 ES036 Rev 8

List of tables

Table 1. Device summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1Table 2. Device identification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1Table 3. Product evolution summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5Table 4. VDD rise-time and fall-time rates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12Table 5. Document revision history . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

ES036 Rev 8 5/26

STM8S007xx STM8S20xxx Product evolution

25

1 Product evolution

Table 3 gives a summary of the fix status.

Legend for Table 3: A = workaround available; N = no workaround available; P = partial workaround available, ‘-’ and grayed = fixed.

Table 3. Product evolution summary

Section Limitation Rev XRev Y/6, V,

W/7, 1

Section 2.1: Core limitations

Section 2.1.1: Activation level (AL) bit not functional in Halt mode

N N

Section 2.1.2: JRIL and JRIH instructions not available

N N

Section 2.1.3: Main CPU execution is not resumed after an ISR resets the AL bit

A A

Section 2.1.4: Unexpected DIV/DIVW instruction result in ISR

A A

Section 2.1.5: Interrupt service routine (ISR) executed with priority of main process

A A

Section 2.1.5: Interrupt service routine (ISR) executed with priority

of main process

Section 2.2.1: HSI RC oscillator cannot be switched off in Run mode

N N

Section 2.2.2: LSI oscillator remains on in Active-halt mode when the AWU unit uses the HSE as input clock

N N

Section 2.2.3: Failure in CAN communication during bootloader

N -

Section 2.2.4: RAM modified after reset by embedded bootloader

N -

Section 2.2.5: Flash / EEPROM memory is read incorrectly after wakeup from power down mode

A A

Section 2.2.6: VDD rise-time rate for 100mV < VDD < 1V

N N

Section 2.3: Timer peripheral limitations

Section 2.3.1: Corruption of read sequence for the 16-bit counter registers

N N

Product evolution STM8S007xx STM8S20xxx

6/26 ES036 Rev 8

Section 2.3: Timer peripheral limitations

Section 2.4.1: PE testing issue in UART mode

N N

Section 2.4.2: LIN mode: LIN header error when automatic resynchronization is enabled

N -

Section 2.4.3: LIN mode: framing error with data byte 0x00

A A

Section 2.4.4: LIN mode: framing error when receiving an identifier (ID)

A A

Section 2.4.5: LIN mode: parity error when receiving an identifier (ID)

A A

Section 2.4.6: LIN mode: OR flag not correctly set in LIN master mode

A A

Section 2.5: I2C peripheral limitations

Section 2.5.1: I2C event management A A

Section 2.5.2: Corrupted last received data in I2C Master Receiver mode

A A

Section 2.5.3: Wrong behavior of I2C peripheral in Master mode after misplaced STOP

A A

Section 2.5.4: Violation of I2C “setup time for repeated START condition” parameter

A A

Section 2.5.5: In I2C slave “NOSTRETCH” mode, underrun errors may not be detected and may generate bus errors

A A

Section 2.5.6: I2C pulse missed A -

Section 2.6: SPI peripheral limitations

Section 2.6.1: Last bit sent is too short if the SPI is disabled during communication

A A

Section 2.6.2: Busy flag is not reliable when the SPI is a master simplex receiver

N N

Table 3. Product evolution summary (continued)


W/7, 1

ES036 Rev 8 7/26

STM8S007xx STM8S20xxx Product evolution

25

Section 2.7: beCAN peripheral limitations

Section 2.7.1: beCAN transmission error when Sleep mode is entered during transmission or reception

A A

Section 2.7.2: beCAN woken up from Sleep mode with automatic wakeup interrupt

A A

Section 2.7.3: beCAN time triggered communication mode not supported

N N

Section 2.7.4: beCAN transmitted data corruption

A -

Section 2.7.5: beCAN read error in slow mode

A A

Section 2.7.6: Write in beCAN paged registers ignored

A A

Section 2.8: Miscellaneous

Section 2.8.1: PWM output available on two different ports (PC4 and PD7) when TIM1_CH4 user option is set

N N

Table 3. Product evolution summary (continued)


W/7, 1

Silicon limitations STM8S007xx STM8S20xxx

8/26 ES036 Rev 8

2 Silicon limitations

2.1 Core limitations

2.1.1 Activation level (AL) bit not functional in Halt mode

Description

The AL bit is not supported in Halt mode. In particular, when the AL bit of the CFG_GCR register is set, the CPU does not return to Halt mode after exiting an interrupt service routine (ISR). It returns to the main program and executes the next instruction after the HALT instruction. The AL bit is supported correctly in WFI mode.

Workaround

No workaround available.

No fix is planned for this limitation.

2.1.2 JRIL and JRIH instructions not available

Description

The JRIL (jump if port INT pin = 0) and JRIH (jump if port INT pin = 1) instructions are not supported by the devices covered by this errata sheet. These instructions perform conditional jumps: JRIL and JRIH jump if one of the external interrupt lines is low or high respectively.

In the devices covered by this errata sheet, JRIL is equivalent to an unconditional jump and JRIH is equivalent to NOP. For further details on these instructions, see the STM8 CPU programming manual (PM0044).

Workaround



2.1.3 Main CPU execution is not resumed after an ISR resets the AL bit

Description

If the CPU is in wait for interrupt state and the AL bit is set, the CPU returns to wait for interrupt state after executing an ISR. To continue executing the main program, the AL bit must be reset by the ISR. When AL is reset just before exiting the ISR, the CPU may remain stalled.

Workaround

Reset the AL bit at least two instructions before the IRET instruction.


ES036 Rev 8 9/26

STM8S007xx STM8S20xxx Silicon limitations

25

2.1.4 Unexpected DIV/DIVW instruction result in ISR

Description

In very specific conditions, a DIV/DIVW instruction may return a false result when executed inside an interrupt service routine (ISR). This error occurs when the DIV/DIVW instruction is interrupted and a second interrupt is generated during the execution of the IRET instruction of the first ISR. Under these conditions, the DIV/DIVW instruction executed inside the second ISR, including function calls, may return an unexpected result.

The applications that do not use the DIV/DIVW instruction within ISRs are not impacted.

Workaround 1

If an ISR or a function called by this routine contains a division operation, the following assembly code should be added inside the ISR before the DIV/DIVW instruction:

push cc

pop a

and a,#$BF

push a

pop cc

This sequence should be placed by C compilers at the beginning of the ISR using DIV/DIVW. Refer to your compiler documentation for details on the implementation and control of automatic or manual code insertion.

Workaround 2

To optimize the number of cycles added by workaround 1, you can use this workaround instead. Workaround 2 can be used in applications with fixed interrupt priorities, identified at the program compilation phase:

push #value

pop cc

where bits 5 and 3 of #value have to be configured according to interrupt priority given by I1 and I0, and bit 6 kept cleared.

In this case, compiler workaround 1 has to be disabled by using compiler directives.


2.1.5 Interrupt service routine (ISR) executed with priority of main process

Description

If an interrupt is cleared or masked when the context saving has already started, the corresponding ISR is executed with the priority of the main process. The next interrupt request can interrupt execution of the service routine

Workaround

At the beginning of the interrupt routine, change the current priority level in the CCR register by software.


10/26 ES036 Rev 8

2.2 System limitations

2.2.1 HSI RC oscillator cannot be switched off in Run mode

Description

The internal 16 MHz RC oscillator cannot be switched off in run mode, even if the HSIEN bit is programmed to 0.

Workaround

No workaround available. No fix planned.

2.2.2 LSI oscillator remains on in Active-halt mode when the AWU unit uses the HSE as input clock

Description

When the auto wake-up unit (AWU) uses the high speed external clock (HSE) divided by the prescaler (clock source enabled by setting the CKAWUSEL option bit), the LSI RC oscillator is not switched off when the device operates in Active Halt mode with the main voltage regulator (MVR) on. This causes negligible extra power consumption compared to the total consumption of the MCU in Active Halt mode with the MVR on.

Workaround

No workaround available. No fix planned.

2.2.3 Failure in CAN communication during bootloader

Description

The CAN filter registers are not initialized by the bootloader. This can lead to failure during communication with the bootloader.

Workaround


2.2.4 RAM modified after reset by embedded bootloader

Description

After each reset, the byte located at RAM address 0x99 is modified by the embedded bootloader even if the bootloader is disabled by option byte. So the RAM content at address 0x99 is not maintained after reset. The limitation is present only in device revision X.

Workaround

No workaround available. Do not use byte in RAM at address 0x99 to store variables which should be unchanged after device reset.

ES036 Rev 8 11/26


25

2.2.5 Flash / EEPROM memory is read incorrectly after wakeup from power down mode

Description

If Flash/EEPROM memory has been put in power down mode (IDDQ), the first read access after wakeup could return incorrect content when fCPU is greater than 250 kHz + 5% and the number of wait states is configured to 0.

By default, the Flash/EEPROM memory is put in IDDQ mode when the MCU enters Halt mode and depending on the FLASH_CR1 register settings made by software, the Flash/EEPROM may be forced to IDDQ mode during active halt mode.

As a consequence, the following behavior may be seen on some devices:

• After wakeup from Low power mode, with Flash memory in IDDQ mode, program execution gets lost due to an incorrect read of the vector table.

• Code reads an incorrect value from Flash/EEPROM memory, when forced in IDDQ mode.

• Reset could be forced by an illegal opcode execution due to incorrect read of instruction.

Note: The use of the watchdog helps the application to recover in case of failure.

Workaround 1

Keep the Flash/EEPROM in operating mode when MCU is put in Halt mode or Active-halt mode. This is done by configuring both the HALT and AHALT bits in the FLASH_CR1 register before executing a HALT instruction to prevent the Flash/EEPROM entering IDDQ mode.

Set HALT (bit 3) to ‘1’:

0: Flash in power-down mode when MCU is in Halt mode

1: Flash in operating mode when MCU is in Halt mode

Keep AHALT (bit 2) at ‘0’:

0: Flash in operating mode when MCU is in Active-halt mode

1: Flash in power-down when MCU is in Active-halt mode

Please refer to the datasheet for details on the impact on current consumption and wakeup time.

Workaround 2

Reduce fCPU frequency to 250 kHz or lower before entering Low power mode to ensure correct Flash memory wakeup. This may be done using the clock divider (CPUDIV[2:0] bits in the CLK_CKDIVR register). The clock divider can be reconfigured back to its previous state by software after wakeup.

This is illustrated by the following code example, assuming no divider is used in the application by default.

CLK_CKDIVR = 0x06;

_asm("HALT");

CLK_CKDIVR = 0x00;


12/26 ES036 Rev 8

The interrupt service routine executed after wakeup could either stay at the slower clock speed, or reconfigure the clock setting. Care has to be taken to restore the previous clock divider setting at the end of interrupt routines when modifying the clock divider.

Workaround 3

Set the number of wait states to 1.

This may be done by setting OPT7 to 0x01.

2.2.6 VDD rise-time rate for 100mV < VDD < 1V

Description

The product datasheet did not specify the VDD rise-time initial conditions as the VDD rise-time was implicitly specified for a VDD starting from 0 V. Nevertheless, it was observed that some very specific applications could have a VDD starting from a residual voltage already above 0 V and thus it is required to explicitly specify these conditions.

The tVDD parameter must stay below 50 μs/V when VDD is rising from 100 mV to 1 V.

Workaround

Not applicable.

2.3 Timer peripheral limitations

2.3.1 Corruption of read sequence for the 16-bit counter registers

Description

An 8-bit buffer is implemented for reading the 16-bit counter registers. Software must read the MS byte first, after which the LS byte value is buffered automatically (see Figure 1). This buffered value remains unchanged until the 16-bit read sequence is completed.

When any multi-cycle instruction precedes the read of the LSB, the content of the buffer is lost and the second read returns the immediate content of the counter directly.

Table 4. VDD rise-time and fall-time rates

Symbol Parameter Conditions Min Typ Max Unit

tVDDVDD rise-time rate

VDD < 100mV 2(1)

1. Guaranteed by design.

- ∞

μs/V100mV < VDD < 1V 2(1) - 50

VDD > 1V 2(1) - ∞

VDD fall-time rate - 2(1) - ∞

ES036 Rev 8 13/26


25

Figure 1. 16-bit read sequence for the counter (TIMx_CNTR)

Workaround

Do not use multi-cycle instructions before reading the LSB.


2.4 UART peripheral limitations

2.4.1 PE testing issue in UART mode

Description

When the RXNE flag is not polled, the device is in overrun condition and the PE flag does not rise in case of a parity error. The flag rises only for the last data which have been correctly received.

Workaround



2.4.2 LIN mode: LIN header error when automatic resynchronization is enabled

Description

If UART3 is configured in LIN slave mode (LSLV bit set in UART3_CR6 register) and the automatic resynchronization is enabled (LASE bit set in UART3_CR6), the LHE flag may be set instead of LHDF flag when receiving a valid header.

Workaround


is bufferedRead

At t0

Read Returns the bufferedLS byte value at t0At t0 +Dt

Otherinstructions

Beginning of the sequence

Sequence completed

LS byte

LS byte

MS byte


14/26 ES036 Rev 8

2.4.3 LIN mode: framing error with data byte 0x00

Description

If the UART3 interface is configured in LIN slave mode, and the active mode with break detection length is set to 11 (LBDL bit of UART3_CR4 register set to 1), FE and RXNE flags are not set when receiving a 0x00 data byte with a framing error, followed by a recessive state. This occurs only if the dominant state length is between 9.56 and 10.56 times the baud rate.

Workaround

The LIN software driver can handle this exceptional case by implementing frame timeouts to comply with the LIN standard. This method has been implemented in ST LIN 2.1 driver package which passed the LIN compliance tests.

2.4.4 LIN mode: framing error when receiving an identifier (ID)

Description

If an ID framing error occurs when the UART3, configured in LIN mode, is in active mode, both the LHE and LHDF flags are set at the end of the LIN header with an ID framing error.

Workaround

The LIN software driver can handle this case by checking both the LHE and LHDF flags upon header reception.


2.4.5 LIN mode: parity error when receiving an identifier (ID)

Description

If an ID parity error occurs, the UART3, configured in LIN mode, wakes up from mute mode and both LHE and LHDF are set at the end of the LIN header with parity error. The PE flag is also set.

Workaround

The LIN software driver can handle this case by checking all flags upon header reception.


2.4.6 LIN mode: OR flag not correctly set in LIN master mode

Description

When the UART operates in LIN master mode, the OR flag is not set if an overrun condition occurs. This is valid for all UARTs (1 to 3).

Workaround

The LIN software driver can detect this case through a LIN protocol error.


ES036 Rev 8 15/26


25

2.5 I2C peripheral limitations

2.5.1 I2C event management

Description

As described in the I2C section of the STM8S and STM8A microcontroller reference manual (RM0016), the application firmware has to manage several software events before the current byte is transferred. If the EV7, EV7_1, EV6_1, EV6_3, EV2, EV8, and EV3 events are not managed before the current byte is transferred, problems may occur such as receiving an extra byte, reading the same data twice, or missing data.

Workaround

When the EV7, EV7_1, EV6_1, EV6_3, EV2, EV8, and EV3 events cannot be managed before the current byte transfer, and before the acknowledge pulse when the ACK control bit changes, it is recommended to use I2C interrupts in nested mode and to make them uninterruptible by increasing their priority to the highest priority in the application.


2.5.2 Corrupted last received data in I2C Master Receiver mode

Conditions

In Master Receiver mode, when the communication is closed using method 2, the content of the last read data may be corrupted. The following two sequences are concerned by the limitation:

• Sequence 1: transfer sequence for master receiver when N = 2a) BTF = 1 (Data N-1 in DR and Data N in shift register)

b) Program STOP = 1

c) Read DR twice (Read Data N-1 and Data N) just after programming the STOP bit.

• Sequence 2: transfer sequence for master receiver when N > 2a) BTF = 1 (Data N-2 in DR and Data N-1 in shift register)

b) Program ACK = 0

c) Read Data N-2 in DR

d) Program STOP bit to 1

e) Read Data N-1.


16/26 ES036 Rev 8

Description

The content of the shift register (data N) is corrupted (data N is shifted 1 bit to the left) if the user software is not able to read data N-1 before the STOP condition is generated on the bus. In this case, reading data N returns a wrong value.

Workarounds

• Workaround 1

– Sequence 1

When sequence 1 is used to close communication using method 2, mask all active interrupts between STOP bit programming and Read data N-1.

– Sequence 2

When sequence 2 is used to close communication using method 2, mask all active interrupts between Read data N-2, STOP bit programming and Read data N-1.

• Workaround 2

Manage I2C RxNE and TxE events with interrupts of the highest priority level, so that the condition BTF = 1 never occurs.

2.5.3 Wrong behavior of I2C peripheral in Master mode after misplaced STOP

Description

The I2C peripheral does not enter Master mode properly if a misplaced STOP is generated on the bus. This can happen in the following conditions:

• If a void message is received (START condition immediately followed by a STOP): the BERR (bus error) flag is not set, and the I2C peripheral is not able to send a START condition on the bus after writing to the START bit in the I2C_CR2 register.

• In the other cases of a misplaced STOP, the BERR flag is set in the IC2_CR2 register. If the START bit is already set in I2C_CR2, the START condition is not correctly generated on the bus and can create bus errors.

Workaround

In the I2C standard, it is not allowed to send a STOP before the full byte is transmitted (8 bits + acknowledge). Other derived protocols like CBUS allow it, but they are not supported by the I²C peripheral.

In case of noisy environment in which unwanted bus errors can occur, it is recommended to implement a timeout to ensure that the SB (start bit) flag is set after the START control bit is set. In case the timeout has elapsed, the peripheral must be reset by setting the SWRST bit in the I2C_CR2 control register. The I2C peripheral should be reset in the same way if a BERR is detected while the START bit is set in I2C_CR2.


ES036 Rev 8 17/26


25

2.5.4 Violation of I2C “setup time for repeated START condition” parameter

Description

In case of a repeated Start, the “setup time for repeated START condition” parameter (named tSU(STA) in the datasheet and Tsu:sta in the I2C specifications) may be slightly violated when the I2C operates in Master Standard mode at a frequency ranging from 88 to 100 kHz. tSU(STA) minimum value may be 4 µs instead of 4.7 µs.

The issue occurs under the following conditions:

1. The I2C peripheral operates in Master Standard mode at a frequency ranging from 88 to 100 kHz (no issue in Fast mode)

2. and the SCL rise time meets one of the following conditions:

– The slave does not stretch the clock and the SCL rise time is more than 300 ns (the issue cannot occur when the SCL rise time is less than 300 ns).

– or the slave stretches the clock.

Workaround

Reduce the frequency down to 88 kHz or use the I2C Fast mode if it is supported by the slave.

2.5.5 In I2C slave “NOSTRETCH” mode, underrun errors may not be detected and may generate bus errors

Description

The data valid time (tVD;DAT, tVD;ACK) described by the I2C specifications may be violated as well as the maximum current data hold time (tHD;DAT) under the conditions described below. In addition, if the data register is written too late and close to the SCL rising edge, an error may be generated on the bus: SDA toggles while SCL is high. These violations cannot be detected because the OVR flag is not set (no transmit buffer underrun is detected).

This issue occurs under the following conditions:

1. The I2C peripheral operates In Slave transmit mode with clock stretching disabled (NOSTRETCH=1)

2. and the application is late to write the DR data register, but not late enough to set the OVR flag (the data register is written before the SCL rising edge).

Workaround

If the master device supports it, use the clock stretching mechanism by programming the bit NOSTRETCH=0 in the I2C_CR1 register.

If the master device does not support it, ensure that the write operation to the data register is performed just after TXE or ADDR events. You can use an interrupt on the TXE or ADDR flag and boost its priority to the higher level.

Using the “NOSTRETCH” mode with a slow I2C bus speed can prevent the application from being late to write the DR register (second condition).


18/26 ES036 Rev 8

Note: The first data to be transmitted must be written into the data register after the ADDR flag is cleared, and before the next SCL rising edge, so that the time window to write the first data into the data register is less than tLOW.

If this is not possible, a possible workaround can be the following:

1. Clear the ADDR flag

2. Wait for the OVR flag to be set

3. Clear OVR and write the first data.

The time window for writing the next data is then the time to transfer one byte. In that case, the master must discard the first received data.

2.5.6 I2C pulse missed

Description

When the I2C interface is used for long transmit/receive transactions, the MCU may return a NACK somewhere during the transaction instead of returning an ACK for all data. The received data may also be corrupted. In Master mode the I2C may not detect an incoming ACK. This is due to a weakness in the noise filter of the I/O pad which in certain conditions may cause the STM8 I2C to miss a pulse.

The workaround described below is not a clean solution. However, the limitation is fixed in revision Y/6 and W/7.

Workaround

Since data corruption is caused by noise generated by the CPU, CPU activity should be minimized during data reception and/or transmission. This is done by performing physical data transmission (Master mode) and reception (slave mode) in WFI state (wait for interrupt).

To allow the device to be woken up from WFI, I2C transmission and reception routines must be implemented through interrupt routines instead of polling mechanisms. Receive and transmit interrupts (received data processing) must be triggered only by the BTF bit flag (byte transfer finished) in the I2C_SR1 register. This flag indicates that the I2C is in stretched state (data transfers are stretched on the bus).

Clock stretching must be enabled to allow data transfers from the slave to be stopped and to allow the CPU to be woken up to read the received byte.

To recover from possible errors, periodically check if the I2C does not remain in busy state for too long (BUSY bit set in I2C_SR3 register). If so, it should be reinitialized.

Example of I2C slave code:

//...

//-----------------------------------------------------------------

void main()

{

Init_I2C(); // init I2C to use interrupts: ITBUFEN=0, ITEVTEN=1, ITERREN=1

while(1)

ES036 Rev 8 19/26


25

2.6 SPI peripheral limitations

2.6.1 Last bit sent is too short if the SPI is disabled during communication

Description

When the SPI interface operates in master mode and the baud rate generator prescaler is equal to 2, the SPI is disabled during ongoing communications, and the data and clock output signals are switched off at the last strobing edge of the SPI clock.

Consequently, the length of the last bit is out of range and its reception on the bus is not ensured.

Workaround

Check if a communication is ongoing before disabling the SPI interface. This can be done by monitoring the BSY bit in the SPI_SR register.


2.6.2 Busy flag is not reliable when the SPI is a master simplex receiver

Description

When the master is receiver only, it provides the clock immediately after setting the SPE bit in the SPI_CR1 register. In this case, the clock is provided until the SPE bit is disabled, meaning that the SPI is always busy because it is in receiver mode only and continuously receives data from the clock. There is no need to read the BUSY bit to know the SPI status because as soon the SPI is enabled, it is BUSY.

Note: The SPE bit has no meaning when the SPI is in master receiver only mode.

Workaround




20/26 ES036 Rev 8

2.7 beCAN peripheral limitations

2.7.1 beCAN transmission error when Sleep mode is entered during transmission or reception

Description

If beCAN Sleep operating mode entry is requested while a transmission or reception is ongoing, or a transmission request is pending, the CAN_TX pin may have a spurious behavior, incompliant with the CAN protocol in case an error occurs on the bus.

No error frame will be sent and the device will enter Sleep mode.

Workaround

Before requesting Sleep mode, request Initialization mode and wait until Initialization mode is entered.

2.7.2 beCAN woken up from Sleep mode with automatic wakeup interrupt

Description

Waking up the beCAN from Sleep mode using the automatic wakeup interrupt triggers an interrupt on each CAN Rx falling edge until the bus is idle.

Workaround

To have a wakeup interrupt triggered only on the first falling edge of the CAN Rx pin, perform the following actions:

1. Disable the automatic wakeup interrupt

2. Clear the WKUI flag

3. Disable the Sleep mode in the ISR

No fix planned.

2.7.3 beCAN time triggered communication mode not supported

Description

The time triggered communication mode described in the STM8A reference manual (RM0016) is not supported.

TTCM bit must be kept at 0 in the CAN_MCR register (time triggered communication mode disabled), and TGT bit in CAN_MDLCR must be initialized to 0 (CAN_MTSRH and CAN_MTSRL registers not sent).

Workaround



ES036 Rev 8 21/26


25

2.7.4 beCAN transmitted data corruption

Description

The TGT bit can be set to 1 (CAN_MTSRH and CAN_MTSRL registers sent) even if the device is not in time triggered communication mode (TTCM set to 1). This is due to the fact that the CAN_MDLCR register reset value is undefined, causing the TGT bit to be set to 1 whatever the value of TTCM. This leads to the corruption of last two data bytes sent.

Workaround

TGT bit in CAN_MDLCR must be initialized to 0 (CAN_MTSRH and CAN_MTSRL registers not sent).

2.7.5 beCAN read error in slow mode

Description

The read byte may be corrupted when the beCAN is in slow mode and a read operation is performed while a transmission is ongoing. This happens because the transmission mailboxes and the receive FIFOs share the same address/data lines for read and write operations.

Workaround

To prevent this problem from occurring, the CPU clock must be the master clock (CLK_CKDIVR[2:0] = 000b) when the user application starts reading the FIFO (CPU clock divider changed to /1). After the FIFO read operation is complete, the CPU clock divider (slow mode) should be applied again.


2.7.6 Write in beCAN paged registers ignored

Description

In very specific conditions, a write to the beCAN paged registers may be ignored. This occurs when the CPU is writing twice or more into beCAN paged registers in consecutive master clock cycles, and during the second or further writes, the CAN 2.0B active core is accessing (read or write) one of the paged registers.

A typical case is when the CPU is writing constants into paged registers (typically a mailbox for transmission) while the CAN 2.0B active core is reading the filters during a frame reception, or writing the FIFO after a frame reception. The beCAN paged registers range is from address 0x5428 to address 0x5437.

Note: CAN 2.0B active core does not access the paged registers as long as the beCAN is in initialization mode. Therefore the issue cannot occur while the software is writing into the paged registers to initialize the beCAN (filter configuration, for example).

The CPU write into two paged registers in two consecutive master clock cycles may only happen in case of consecutive single-cycle load and transfer instructions or single-cycle bit operation instructions, when the destination is an address within the range 0x5428 to 0x5437 inside the beCAN peripheral. The instructions are single-cycle if the source is a constant (embedded in instruction opcode) or in the A accumulator (when the same value has to be stored in two or more CAN registers).


22/26 ES036 Rev 8

List of instructions:

MOV longmem, #byte ; LD longmem, A ; CLR longmem

Examples:

• Consecutive MOV instructions with immediate addressing mode

MOV 0x5429, #0x08

MOV 0x542a, #0x0d

MOV 0x542b, #0x40

• Consecutive LD instructions with A register as source

LD 0x542d, A

LD 0x542e, A

• CLR instruction followed by another single-cycle instruction

CLR 0x542d

MOV 0x542e, #0x40

• Mix of single-cycle instructions

LD 0x5429, A

MOV 0x542a, #0x0d

Consecutive single-cycle bit instruction BSET, BRST, BCPL might also generate the case.


BSET longmem, n ; BRES longmem, n ; BCPL longmem, n

Another very unlikely case is indirect or indexed addressing with beCAN address loaded in X or Y registers, which also generates single-cycle instructions.


LD (X), A ; LD (shortoff,X),A ; LD (longoff,X),A ; LD (Y), A ; LD (shortoff, Y) ; LD (longoff, Y) ; CLR (X) ; CLR (shortoff,X) ; CLR (longoff,X) ; CLR (Y) ; CLR (shortoff,Y) ; CLR (longoff,Y) ; CLR (shortoff, SP)

This can also happen with a single 2-cycle LDW instruction, if two consecutive registers are written with a 16-bit data, with X or Y register as source.


LDW longmem, X ; LDW longmem, Y

Example:

LDW 0x542a, X ; with X containing 0x0d40.

ES036 Rev 8 23/26


25

The issue may happen typically if the software is filling paged registers with constants.

Example:

#define MY_ID (unsigned int) 0x0350

[…]

CAN_MDLCR = 0x08;

CAN_MIDR1 = (MY_ID >> 6) & 0x1F;

CAN_MIDR2 = (MY_ID << 2) & 0xFC;

This generates the following code:

35085429 mov 0x5429, #8

350d542a mov 0x542a, #13

3540542b mov 0x542b, #64

If the beCAN paged registers are not written with constants, and if beCAN paged registers are written with the value of an 8-bit variable, this is very unlikely to fall into one of these cases, as either 2-cycle instructions are generated by the compiler or an additional instruction is inserted between two beCAN accesses (loading the variable into the A accumulator).

Impact on application

When all the specific conditions are met, a corrupted frame may be sent to the CAN bus.

Workaround

In case you need to write consecutively into paged registers, insert a NOP instruction in between each write. You can make use of inline assembly in C code.

Example:

#define MY_ID (unsigned int) 0x0350

[…]

CAN_P1 = 0x08;

_asm(nop");

CAN_P2 = (MY_ID >> 6) & 0x1F;

_asm(nop");

CAN_P3 = (MY_ID << 2) & 0xFC;



24/26 ES036 Rev 8

2.8 Miscellaneous

2.8.1 PWM output available on two different ports (PC4 and PD7) when TIM1_CH4 user option is set

Description

When the TIM1_CH4 alternate function remapping option is set (via option byte AFR4 bit), pulse-width modulation (PWM) output is available on both PC4 and PD7.

The TIM1_CH4 option is reserved only for 44 pin packages where PC4 is not present.

Workaround



ES036 Rev 8 25/26

STM8S007xx STM8S20xxx Revision history

25

3 Revision history

Table 5. Document revision history

Date Revision Changes

07-Jul-2010 1 Initial release

07-Mar-2011 2

Added revision Y/6.

Added Section 2.1.4: Unexpected DIV/DIVW instruction result in ISR and Section 2.4.3: LIN mode: framing error with data byte 0x00.

Updated Section 2.5: I2C peripheral limitations and Appendix A: Revision code on device marking.

Removed all references to UART2.

Restructured document and changed layout ofTable 3.

04-Jul-2011 3Added revision W/7.

Updated Section 2.5.6: I2C pulse missed and Section 2.7.4: beCAN transmitted data corruption.

19-Mar-2012 4Added reference STM8S007xx throughout the document.

Added Section 2.7.6: Write in beCAN paged registers ignored.

14-Mar-2013 5Updated Table 1: Device summary.

Modified Section 2.7.1: beCAN transmission error when Sleep mode is entered during transmission or reception.

06-Dec-2013 6

Added Section 2.1.5: Interrupt service routine (ISR) executed with priority of main process

Added Section 2.2.4: RAM modified after reset by embedded bootloader

Added Section 2.2.5: Flash / EEPROM memory is read incorrectly after wakeup from power down mode.

Added Section 2.3.1: Corruption of read sequence for the 16-bit counter registers

25-Apr-2019 7

Added:

– Section 2.2.6: VDD rise-time rate for 100mV < VDD < 1V

Updated:

– Table 1: Device summary

– Table 2: Device identification footnote

– Table 3: Product evolution summary

Deleted:

– List of tables

– Appendix A: Revision code on device marking

02-Oct-2019 8 Added revision 1.

STM8S007xx STM8S20xxx

26/26 ES036 Rev 8

IMPORTANT NOTICE – PLEASE READ CAREFULLY

STMicroelectronics NV and its subsidiaries (“ST”) reserve the right to make changes, corrections, enhancements, modifications, and improvements to ST products and/or to this document at any time without notice. Purchasers should obtain the latest relevant information on ST products before placing orders. ST products are sold pursuant to ST’s terms and conditions of sale in place at the time of order acknowledgement.

Purchasers are solely responsible for the choice, selection, and use of ST products and ST assumes no liability for application assistance or the design of Purchasers’ products.

No license, express or implied, to any intellectual property right is granted by ST herein.

Resale of ST products with provisions different from the information set forth herein shall void any warranty granted by ST for such product.

ST and the ST logo are trademarks of ST. For additional information about ST trademarks, please refer to www.st.com/trademarks. All other product or service names are the property of their respective owners.

Information in this document supersedes and replaces information previously supplied in any prior versions of this document.

© 2019 STMicroelectronics – All rights reserved

Documents

STM8S007xx STM8S20xxx Errata sheet - STMicroelectronics€¦ · 2 Silicon limitations 2.1 Core limitations 2.1.1 Activation level (AL) bit not functional in Halt mode Description