STM8S003F3 usage summary - serial port

As a low-cost chip, STM8 has been favored by many users. A recent project used the STM8S003F3P6 chip, and its main function was to control PWM output by receiving serial port instructions. Here is a summary of the problems encountered in the use of this chip.

Compilation environment: IAR for STM8 3.10.2

Library version: V2.2.0

1. Differences between STM8S003F3 and STM8S103F3

In addition to the above differences, the two chips are pin-to-pin compatible and have the same on-chip peripheral resources.

2.Serial communication

STM8S003F does not support DMA, so it uses interrupt mode for reception. The interrupt vector table is as follows:

typedef enum { UART1_IT_TXE = (uint16_t)0x0277, /*!< Transmit interrupt */

               UART1_IT_TC = (uint16_t)0x0266, /*!< Transmission Complete interrupt */

               UART1_IT_RXNE = (uint16_t)0x0255, /*!< Receive interrupt */

               UART1_IT_IDLE = (uint16_t)0x0244, /*!< IDLE line interrupt */

               UART1_IT_OR = (uint16_t)0x0235, /*!< Overrun Error interrupt */

               UART1_IT_PE = (uint16_t)0x0100, /*!< Parity Error interrupt */

               UART1_IT_LBDF = (uint16_t)0x0346, /**< LIN break detection interrupt */

               UART1_IT_RXNE_OR = (uint16_t)0x0205 /*!< Receive/Overrun interrupt */

             } UART1_IT_TypeDef;

There are two types of RX interrupts, UART1_IT_RXNE and UART1_IT_RXNE_OR. During use, only UART1_IT_RXNE_OR can trigger an interrupt, while UART1_IT_RXNE interrupt will cause the program to run away. With doubts, I searched for related questions and library functions on the Internet and found the problem. In the parameter check function:

assert_param(IS_UART1_CONFIG_IT_OK(UART1_IT));

Among them, IS_UART1_CONFIG_IT_OK is defined as follows:

#define IS_UART1_CONFIG_IT_OK(Interrupt)

  (((Interrupt) == UART1_IT_PE) ||

   ((Interrupt) == UART1_IT_TXE) ||

   ((Interrupt) == UART1_IT_TC) ||

   ((Interrupt) == UART1_IT_RXNE_OR ) ||

   ((Interrupt) == UART1_IT_IDLE) ||

   ((Interrupt) == UART1_IT_LBDF))

There is no UART1_IT_RXNE in the definition, so UART1_IT_RXNE will be regarded as an illegal parameter. Similarly, the same situation will occur if the UART1_IT_OR interrupt is used. There are two solutions:

Use UART1_IT_RXNE_OR as the receive interrupt;

Redefine IS_UART1_CONFIG_IT_OK to:

#define IS_UART1_CONFIG_IT_OK(Interrupt)

  (((Interrupt) == UART1_IT_PE) ||

   ((Interrupt) == UART1_IT_TXE) ||

   ((Interrupt) == UART1_IT_TC) ||

   ((Interrupt) == UART1_IT_RXNE_OR ) ||

   ((Interrupt) == UART1_IT_RXNE ) || //Redefine content

   ((Interrupt) == UART1_IT_IDLE) ||

   ((Interrupt) == UART1_IT_LBDF))

However, after going through many difficulties, the same problem occurred again when clearing the interrupt flag after entering the receive interrupt. . .

Following the original idea, I found that the problem was still the same. The definition of IS_UART1_CLEAR_IT_OK in the check parameter function is as follows:

#define IS_UART1_CLEAR_IT_OK(ITPendingBit)

  (((ITPendingBit) == UART1_IT_RXNE) ||

   ((ITPendingBit) == UART1_IT_LBDF))

I started to doubt my life. There are only two interrupt flag options in the parameter table. WTF… The solution is the same as above. I directly cleared the UART1_IT_RXNE interrupt flag.