2025-05-02 1:47 PM
Hi, with STM32F030C8T6, I am implemeting MODBUS protocol in RTU (Slave) with UART as physicsl layer. I use QModMaster (A master simulation software run in PC). I use oscilloscope to probe the actual information through the RS485.
Recently I inplemented different baudrate and parity settings. While testing, I observed that data sent from master (QModMaster software running in PC) is correctly intrepreted by STM32 even when paity is flipped.
For example, if master sends a data with Even parity, STM32 undertsand the data for both EVen paity as well as Odd paity. Buut when no paity is set in STM32, data is not understood by it.
Similarly, if I set Odd paity in master, even then data is unserstood by STM32 is correct with Even paity and Odd paity.
I am not so happy since this works in this way.
For your info I have pasted by UART init code below:
void USART1_Init(void)
{
// Enable GPIOB and USART1 clocks
RCC->AHBENR |= RCC_AHBENR_GPIOBEN;
RCC->APB2ENR |= RCC_APB2ENR_USART1EN;
// --- PB5 as DE (Driver Enable) ---
GPIOB->MODER &= ~(3 << (5 * 2)); // Clear PB5 mode
GPIOB->MODER |= (1 << (5 * 2)); // Set PB5 as output
GPIOB->OTYPER &= ~(1 << 5); // Push-pull
GPIOB->OSPEEDR |= (3 << (5 * 2)); // High speed
GPIOB->PUPDR &= ~(3 << (5 * 2)); // No pull-up/down
GPIOB->ODR &= ~(1 << 5); // Set PB5 LOW (receive mode by default)
// --- PB6 as USART1_TX (with pull-up) ---
GPIOB->MODER &= ~(3 << (6 * 2)); // Clear PB6 mode
GPIOB->MODER |= (2 << (6 * 2)); // Set PB6 as alternate function
GPIOB->OTYPER &= ~(1 << 6); // Push-pull
GPIOB->OSPEEDR |= (3 << (6 * 2)); // High speed
GPIOB->PUPDR &= ~(3 << (6 * 2)); // Clear pull-up/down
GPIOB->PUPDR |= (1 << (6 * 2)); // Enable pull-up
GPIOB->AFR[0] &= ~(0xF << (6 * 4)); // Clear AF
GPIOB->AFR[0] |= (0x0 << (6 * 4)); // AF0 (USART1_TX on PB6)
// --- PB7 as USART1_RX (with pull-up) ---
GPIOB->MODER &= ~(3 << (7 * 2)); // Clear PB7 mode
GPIOB->MODER |= (2 << (7 * 2)); // Set PB7 as alternate function
GPIOB->OTYPER &= ~(1 << 7); // Push-pull
GPIOB->OSPEEDR |= (3 << (7 * 2)); // High speed
GPIOB->PUPDR &= ~(3 << (7 * 2)); // Clear pull-up/down
GPIOB->PUPDR |= (1 << (7 * 2)); // Enable pull-up
GPIOB->AFR[0] &= ~(0xF << (7 * 4)); // Clear AF
GPIOB->AFR[0] |= (0x0 << (7 * 4)); // AF0 (USART1_RX on PB7)
// --- USART1 Config ---
USART1->CR1 &= ~(USART_CR1_UE); // Disable USART before config
USART1->BRR = Set_USART1_BRR; // Baud = 9600 (assuming 8 MHz HSE)
if(Set_Parity==0) {Switch_Relay_1_ON;} else {Switch_Relay_1_OFF;}
if(Set_Parity==1) {Switch_Relay_2_ON;} else {Switch_Relay_2_OFF;}
if(Set_Parity==2) {Switch_Relay_3_ON;} else {Switch_Relay_3_OFF;}
switch(Set_Parity)
{
case 0: // No parity, 1 start bit, 8 data bits, 2 stop bits. Totally 11 bits
USART1->CR1 &= ~USART_CR1_PS;
USART1->CR1 &= ~USART_CR1_PCE;
USART1->CR1 &= ~USART_CR1_M;
USART1->CR2 &= ~USART_CR2_STOP_0;
USART1->CR2 |= USART_CR2_STOP_1;
break;
case 1: // Even parity, 1 start bit, 8 data bits, 1 parity bit, 1 stop bit. Totally 11 bits
USART1->CR1 &= ~USART_CR1_PS;
USART1->CR1 |= USART_CR1_PCE;
USART1->CR1 |= USART_CR1_M;
USART1->CR2 &= ~USART_CR2_STOP_0;
USART1->CR2 &= ~USART_CR2_STOP_1;
break;
case 2: // Odd parity, 1 start bit, 8 data bits, 1 parity bit, 1 stop bit. Totally 11 bits
USART1->CR1 |= USART_CR1_PS;
USART1->CR1 |= USART_CR1_PCE;
USART1->CR1 |= USART_CR1_M;
USART1->CR2 &= ~USART_CR2_STOP_0;
USART1->CR2 &= ~USART_CR2_STOP_1;
break;
}
//USART1->CR1 |= USART_CR1_OVER8;
USART1->CR1 |= USART_CR1_TE | USART_CR1_RE; // Enable TX and RX
USART1->CR1 |= USART_CR1_RXNEIE; // Enable RX interrupt
USART1->CR1 |= USART_CR1_UE; // Enable USART
NVIC_EnableIRQ(USART1_IRQn); // Enable USART1 IRQ
}
For more info I sent photos of osciloscope screen with matching parity and non matching parity setting and comparison of plots.
Since scope too inyerpretts teh data correctly, but with red highlights I cant blame STM32 and the software. Something is not understandable for me. Please help me to know whats going on here.
Solved! Go to Solution.
2025-05-02 2:13 PM
Are you checking for the parity error (PE) bit being set?
On the scope, I suspect red text indicates an incorrect parity bit.
2025-05-02 2:13 PM
Are you checking for the parity error (PE) bit being set?
On the scope, I suspect red text indicates an incorrect parity bit.
2025-05-02 4:38 PM
Oh my god, you are the king.
Yes I did not properly check PE flag. Baremetal code :) Now I checked and properly implemented in IRQ handler. Thank you so much.