STM32F302R8 USART Register does not match with Reference Manual

[Glenn0010]

Hi All,

I have been trying to get the USART2 talking to my PC for a while now on my nucleo. I had everything initialized "correctly" however when I talk to the PC via a simple echo program, I would some times receive the wrong character. which didn't add up.

After quadruple checking everything and realizing that everything was "correct" I decided to switch the data bits from the PC side to 7 and everything worked perfectly. So than I started to check and cross reference with the manual.

The datasheet clearly shows that bits 28 and 12, M1 and M0 respectively, set the word length. So when they are set to 00 the data bits are 8 bits.


So I debugged the code and check it. Below it shows clearly that the register value indicates that both of them are 0. However as shown in the debugger view while the register value reflects this, there is only one "M" bit set and it is bit 12. Bit 28 is not show there at all. So basically in 7 bit mode it works flawlessly however in 8 bit mode it doesn't work at all despite the reference manual saying otherwise.
 
Can anyone shed some light on this?




Cheers

[TK]

I find it much easier to use STM32CUBEMX + HAL to program STM32 devices, at least when you are starting and need to make initial testings of each peripheral until you get the output / input you expect correctly

[lucazader]

I have used the F302C8 in the past and have had no issues with this.

I would have been using the Cube generated code, but we use 8n1 uart all over the place in our products and have never encountered this issue

[Freddie Chopin]

Check the very beginning of the chapter about USART in the reference manual.

29.4. USART implementation
Table 152. STM32F302xx USART features

Your chip supports only 8 or 9 bits, that's why there is actually only ONE of the "M" bits - the other is not implemented for your chip.

Now about your real issue. STM32 are a bit strange when you enable parity. You would expect that when you set the word length to 8 bits it's 8 bits - no matter if parity is enabled or not. However it's not the case. If you do _NOT_ use parity, then all of these data bits are for you to use, so it's 8N1. However if you change just the single PCE bit, enabling parity, then instead of adding one bit for parity (as you most likely expected) it actually uses one of your 8 bits for parity, leaving just 7 for you. So 8N1 becomes 7E1 (or 7O1) by changing just PCE bit.

Therefore if you want parity enabled, you have to actually set one bit more than you want to use - for 8 bits of data and parity, you should configure UART for 9 bits. Confusing, but that's how it is. It is mentioned somewhere in the chapter about USART, just take a very close look. Even the description of PCE hints it:

"This bit selects the hardware parity control (generation and detection). When the parity control is enabled, the computed parity is inserted at the MSB position (9th bit if M=1; 8th bit if M=0) and parity is checked on the received data."

[capt bullshot]

Same for me - used many variants from F0 to F7 and L4,
Used either old standard peripheral library code or new HAL code for initialization, combined with my own UART driver code, never ran into issues with that. And never dug into the bits of the UART config registers.
There's some subtle differences between the UARTs on the various models.

[Freddie Chopin]

Most of you did not experience this issue just because you did not use parity. Check my edited post above.

[capt bullshot]

Most of you did not experience this issue just because you did not use parity. Check my edited post above.

Yes, never used parity. From my limited experience, it's quite uncommon to use the parity today. Anyway, thanks for the enlightenment, I might remember you if I ever need to use parity on STM UARTs.

[Glenn0010]

I find it much easier to use STM32CUBEMX + HAL to program STM32 devices, at least when you are starting and need to make initial testings of each peripheral until you get the output / input you expect correctly

To be honest. I don't like using the HAL system. I'm sure its very convenient and quick. However, I like to understand full what is going on and know where everything is. I feel like once you initialise a peripheral once, you can get quite quick at doing things.
Modify message

[Glenn0010]

It's STM32, so this is normal.

Have you had similar experiences in the past?

[Glenn0010]

I have used the F302C8 in the past and have had no issues with this.

I would have been using the Cube generated code, but we use 8n1 uart all over the place in our products and have never encountered this issue

I have used the cube briefly but prefer to do everything manully so I understand what is going on. Granted it is a lot more time consuming however I don't have deadlines or anything. This is just aproject I play with. There are some slight differences Between the F302CB and FR302R8 with regards to the UART so maybe that has something to do with it.

[Glenn0010]

Check the very beginning of the chapter about USART in the reference manual.

29.4. USART implementation
Table 152. STM32F302xx USART features

Your chip supports only 8 or 9 bits, that's why there is actually only ONE of the "M" bits - the other is not implemented for your chip.

Now about your real issue. STM32 are a bit strange when you enable parity. You would expect that when you set the word length to 8 bits it's 8 bits - no matter if parity is enabled or not. However it's not the case. If you do _NOT_ use parity, then all of these data bits are for you to use, so it's 8N1. However if you change just the single PCE bit, enabling parity, then instead of adding one bit for parity (as you most likely expected) it actually uses one of your 8 bits for parity, leaving just 7 for you. So 8N1 becomes 7E1 (or 7O1) by changing just PCE bit.

Therefore if you want parity enabled, you have to actually set one bit more than you want to use - for 8 bits of data and parity, you should configure UART for 9 bits. Confusing, but that's how it is. It is mentioned somewhere in the chapter about USART, just take a very close look. Even the description of PCE hints it:

"This bit selects the hardware parity control (generation and detection). When the parity control is enabled, the computed parity is inserted at the MSB position (9th bit if M=1; 8th bit if M=0) and parity is checked on the received data."

Hi Freddie,

Thanks for your in-depth reply. I have looked at the manual again and Table 152 shows the the F302R8 (which is what I am using), does in fact support 7,8 or 9 bits as seend below, therefore it should have 2 "M" bits. Unless I have a different version of the Ref Manual but it is the latest one from the ST website I believe.



I have tried with both the parity bits on and off. When the PC side was set to 8 bits with PE on and PE off I was getting the wrong characters in both cases. However when I set the PC side to 7 bits, both with PE on and PE off, I always get the right characters back which is odd because as you said table 157 indicates otherwise.

Furthermore, I have checked that I am using the right Software Pack for my specific IC within Keil and that I have the latest version of it.

Even though it is working currently I would like to figure out what is going on, maybe I have a wrong version of the manual or something or maybe it is some compiler issues.

Any help is very appreciated

[Freddie Chopin]

Show the complete code you have to configure the peripheral. For a start please try to use 8N1, as it will be easier to trace the issue with one configuration instead of N different configurations.

Also don't pay much attention to what the plugin in the debugger shows you - RM is the definitive source, so it it says you have two "M" bits then you have two of them, even if debugger tries to say otherwise.

Please also tell what is your clock source and how precise it is.

[Glenn0010]

Show the complete code you have to configure the peripheral. For a start please try to use 8N1, as it will be easier to trace the issue with one configuration instead of N different configurations.

Also don't pay much attention to what the plugin in the debugger shows you - RM is the definitive source, so it it says you have two "M" bits then you have two of them, even if debugger tries to say otherwise.

Please also tell what is your clock source and how precise it is.

I will post the code when I get home from work.

But I am running USART2 off the APB1 bus at  32MHz (APB1 max is 36MHz).. however, I am using the HSI (Internal Oscillator) which I know is not as accurate as the external 8MHz (IIRC) Oscillator which is provided on the Nucleo, so I don't know if that could be an issue.

Cheers

[Freddie Chopin]

however, I am using the HSI (Internal Oscillator) which I know is not as accurate as the external 8MHz (IIRC) Oscillator which is provided on the Nucleo, so I don't know if that could be an issue.

It could. Do you have a scope or a logic analyzer?

[techman-001]

Also don't pay much attention to what the plugin in the debugger shows you - RM is the definitive source, so it it says you have two "M" bits then you have two of them, even if debugger tries to say otherwise.

Actually I think the STM32F302xSVD file may be the definitive source as there are errors in the STM32F Reference Manuals here and there. This isn't surprising when one considers the *massive* numbers of peripherals, registers and bit-fields in their enormous range of MCU's.

The STM32F302x.svd shows no bit 28 in USARTX_CR1. The words "Word length" (CR1_M) only occur for bit 12 in USARTX_CR1.

This is a Forth Word List generated from STM32F302x.svd, but it shows the full bitfield names and descriptions.

\ USART2_CR1 (read-write)
: USART2_CR1_EOBIE   %1 27 lshift USART2_CR1 bis! ;  \ USART2_CR1_EOBIE    End of Block interrupt enable
: USART2_CR1_RTOIE   %1 26 lshift USART2_CR1 bis! ;  \ USART2_CR1_RTOIE    Receiver timeout interrupt enable
: USART2_CR1_DEAT   ( %XXXXX -- ) 21 lshift USART2_CR1 bis! ;  \ USART2_CR1_DEAT    Driver Enable assertion time
: USART2_CR1_DEDT   ( %XXXXX -- ) 16 lshift USART2_CR1 bis! ;  \ USART2_CR1_DEDT    Driver Enable deassertion time
: USART2_CR1_OVER8   %1 15 lshift USART2_CR1 bis! ;  \ USART2_CR1_OVER8    Oversampling mode
: USART2_CR1_CMIE   %1 14 lshift USART2_CR1 bis! ;  \ USART2_CR1_CMIE    Character match interrupt enable
: USART2_CR1_MME   %1 13 lshift USART2_CR1 bis! ;  \ USART2_CR1_MME    Mute mode enable
: USART2_CR1_M   %1 12 lshift USART2_CR1 bis! ;  \ USART2_CR1_M    Word length
: USART2_CR1_WAKE   %1 11 lshift USART2_CR1 bis! ;  \ USART2_CR1_WAKE    Receiver wakeup method
: USART2_CR1_PCE   %1 10 lshift USART2_CR1 bis! ;  \ USART2_CR1_PCE    Parity control enable
: USART2_CR1_PS   %1 9 lshift USART2_CR1 bis! ;  \ USART2_CR1_PS    Parity selection
: USART2_CR1_PEIE   %1 8 lshift USART2_CR1 bis! ;  \ USART2_CR1_PEIE    PE interrupt enable
: USART2_CR1_TXEIE   %1 7 lshift USART2_CR1 bis! ;  \ USART2_CR1_TXEIE    interrupt enable
: USART2_CR1_TCIE   %1 6 lshift USART2_CR1 bis! ;  \ USART2_CR1_TCIE    Transmission complete interrupt enable
: USART2_CR1_RXNEIE   %1 5 lshift USART2_CR1 bis! ;  \ USART2_CR1_RXNEIE    RXNE interrupt enable
: USART2_CR1_IDLEIE   %1 4 lshift USART2_CR1 bis! ;  \ USART2_CR1_IDLEIE    IDLE interrupt enable
: USART2_CR1_TE   %1 3 lshift USART2_CR1 bis! ;  \ USART2_CR1_TE    Transmitter enable
: USART2_CR1_RE   %1 2 lshift USART2_CR1 bis! ;  \ USART2_CR1_RE    Receiver enable
: USART2_CR1_UESM   %1 1 lshift USART2_CR1 bis! ;  \ USART2_CR1_UESM    USART enable in Stop mode
: USART2_CR1_UE   %1 0 lshift USART2_CR1 bis! ;  \ USART2_CR1_UE    USART enable

[Glenn0010]

Also don't pay much attention to what the plugin in the debugger shows you - RM is the definitive source, so it it says you have two "M" bits then you have two of them, even if debugger tries to say otherwise.

Actually I think the STM32F302xSVD file may be the definitive source as there are errors in the STM32F Reference Manuals here and there. This isn't surprising when one considers the *massive* numbers of peripherals, registers and bit-fields in their enormous range of MCU's.

The STM32F302x.svd shows no bit 28 in USARTX_CR1. The words "Word length" (CR1_M) only occur for bit 12 in USARTX_CR1.

This is a Forth Word List generated from STM32F302x.svd, but it shows the full bitfield names and descriptions.

Interesting, so can you add this manually somehow? Or how do you propose to get around/fix the issue?? As it does not inspire me with confidence even through it is working fine now

[techman-001]

Also don't pay much attention to what the plugin in the debugger shows you - RM is the definitive source, so it it says you have two "M" bits then you have two of them, even if debugger tries to say otherwise.

Actually I think the STM32F302xSVD file may be the definitive source as there are errors in the STM32F Reference Manuals here and there. This isn't surprising when one considers the *massive* numbers of peripherals, registers and bit-fields in their enormous range of MCU's.

The STM32F302x.svd shows no bit 28 in USARTX_CR1. The words "Word length" (CR1_M) only occur for bit 12 in USARTX_CR1.

This is a Forth Word List generated from STM32F302x.svd, but it shows the full bitfield names and descriptions.

Interesting, so can you add this manually somehow? Or how do you propose to get around/fix the issue?? As it does not inspire me with confidence even through it is working fine now

I'm not sure there is anything to fix (unless I don't understand your problem), I'm only saying that your debugger and my SVD parser (which probably both use the same SVD file) agree that there is no 7 bit option in any of the STM32F302R8 USART's.

Glenn0010 at 04:32:06 pm explained the parity issue.

[Glenn0010]

however, I am using the HSI (Internal Oscillator) which I know is not as accurate as the external 8MHz (IIRC) Oscillator which is provided on the Nucleo, so I don't know if that could be an issue.

It could. Do you have a scope or a logic analyzer?

I do, do you reccomend looking at the mcu clock?. I could try to use the ext Oscillator as the source and see if that works.

[Freddie Chopin]

I do, do you reccomend looking at the mcu clock?. I could try to use the ext Oscillator as the source and see if that works.

No, don't waste time looking with your scope/analyzer at the clock. Look at what you are sending out on UART's TX pin when trying to transmit patterns like 0x55 or 0xaa. And show your code (;

[Glenn0010]

I do, do you reccomend looking at the mcu clock?. I could try to use the ext Oscillator as the source and see if that works.

No, don't waste time looking with your scope/analyzer at the clock. Look at what you are sending out on UART's TX pin when trying to transmit patterns like 0x55 or 0xaa. And show your code (;

So I didn't have much time to play with things this week but can mess round with it in the weekend. Here is my initialization code.

Code: [Select]


//------------------------------------ UART Enable -------------------------------------
RCC->APB1ENR |= RCC_APB1ENR_USART2EN; // Enabling USART2 Clock
RCC->AHBENR |= RCC_AHBENR_GPIOAEN;    // Enabling Port A

GPIOA->MODER |= GPIO_MODER_MODER2_1 | GPIO_MODER_MODER3_1;  // Setting PA2, PA3 as alternate function mode
GPIOA->PUPDR |= GPIO_PUPDR_PUPDR2_0 | GPIO_PUPDR_PUPDR3_0;  // Setting PA2, PA3 as pull ups.
GPIOA->AFR[0] = 0x7700; // Alternate Functions USART 2 For PA2, PA3
 
USART2->CR1 = USART_CR1_TE | USART_CR1_RE | USART_CR1_RXNEIE | USART_CR1_PCE | USART_CR1_PS  ; //USART_CR1_TXEIE // Transmit Enable, Revive Enable, RX not empty Int Enable, TX not empty Int Enable
USART1->CR3 = (USART1->CR3 & 0xFFFFFCFF);
USART1->CR2 = (USART1->CR2 & ~USART_CR2_STOP); // 1 stop bit
USART2->BRR = pckl1f/9600; // 32MHz / 9600
USART2->CR1 |=  USART_CR1_UE; // Uart Enable


NVIC_EnableIRQ(USART2_IRQn); // Enabling USART2 interrupt
And here is my ISR

Code: [Select]

void USART2_IRQHandler(void)
{
  if((USART2->ISR & USART_ISR_RXNE) == USART_ISR_RXNE)
{
USART2->TDR = USART2->RDR & 0xFF;
if ((USART2->ISR & USART_ISR_NE) == USART_ISR_NE)
{
USART2->ICR = USART_ICR_NCF;
}
}

}
This current version has Parity Enabled, but as I said when I set the PC to 7 bit mode, both with parity and without parity they worked flawlessly. However in 8 bit mode both with and without parity, I get wrong characters.

[Freddie Chopin]

Your code looks correct, but please note that you actually configured your UART for 7O1 - 7 bits of data, odd parity, 1 stop bits. Therefore it is perfectly normal that it works when you set Windows to 7-bits too. The fact that it works no matter it you enable parity on Windows' side is irrelevant - you don't check for PE (parity error) flag in your code, so STM32 actually ignores parity errors. Why the data is received on Windows is another question, but not really relevant here.

To set your UART to 8N1 just drop "USART_CR1_PCE | USART_CR1_PS" from your code. Then send some patterns like 0x55, 0xaa, 0x1, 0x80, 0x0, 0xff and check with your scope/analyzer.

[Glenn0010]

Your code looks correct, but please note that you actually configured your UART for 7O1 - 7 bits of data, odd parity, 1 stop bits. Therefore it is perfectly normal that it works when you set Windows to 7-bits too. The fact that it works no matter it you enable parity on Windows' side is irrelevant - you don't check for PE (parity error) flag in your code, so STM32 actually ignores parity errors. Why the data is received on Windows is another question, but not really relevant here.

To set your UART to 8N1 just drop "USART_CR1_PCE | USART_CR1_PS" from your code. Then send some patterns like 0x55, 0xaa, 0x1, 0x80, 0x0, 0xff and check with your scope/analyzer.

So I've had a quick look with the scope and I think I understand what's going on.

When I send 0x55 via the PC sometimes I receive 0x55 and sometime I receive 0xD5. That is a difference of one bit. Furthermore, If I  send a constant char from the uC it always is received perfectly by the PC.  So what I think is happening here is that the buad rate is sometimes off.and accumulates as the bits are sent. so as the MSB is approached, you get the error as happens in this case. Now this does not explain why it works when the PC end is set to 7 bit mode.

Further mode if you want to send an 8 bit value in 7 bit mode how is it actually transmitted? It must be done in two frames correct? As I have tried looking at the frame but it was hard to discern what was going as I assume another frame is added instantly after the first one.

So my plan is to add an external 8MHz Oscillator and use that as my main clock. Firstly it allows me  run the STM at its max Freq and also is more accurate. I am currently using the internal HSI which is not as stable as the external one as per the datasheet and I am not running the calibration for it on power up which I assume makes thins worse. SoI'll just use and external XTAL

Any thoughts?

[Freddie Chopin]

If you think the baudrate is off, then check the frequency with the scope. Generally your error should be very very low if the bus clock for USART2 is really 32 MHz. Usually it is assumed that <2% is OK, while for your case its just 0.01%...

Further mode if you want to send an 8 bit value in 7 bit mode how is it actually transmitted? It must be done in two frames correct? As I have tried looking at the frame but it was hard to discern what was going as I assume another frame is added instantly after the first one.

No - it you configure UART to be 7 bits, then just the lower 7 bits of what you write to USARTx->TDR are transmitted. This means that you actually cannot transmit 0xaa or 0xff - they will be clipped to 0x2a or 0x3f.

Can you make screenshots of your scope?

Now this does not explain why it works when the PC end is set to 7 bit mode.

As long as the MSB of what you transmit from STM32 to PC is high (either because the parity bit was high or because the data actually has MSB set) then it will be received correctly - the MSB, when high, will be taken as the stop bit. If you transmit from PC as 7 bits to your STM32 it will receive it no matter what and you will get a RXNE interrupt. There may be a parity error (if the parity does not match) or a framing error (if there is no proper stop bit), but you completely ignore these errors, so they just don't matter at all. It's not that if you configure both ends to different format you'll get absolute silence - you usually will get something, quite frequently this "something" is 100% correct. But also note that on STM32 you ignore almost any possible error, so as long as you're not sending white noise, the MCU will actually receive proper data.

Don't get me wrong, but you are approaching the "problem" from the very wrong direction. The code as you presented does set 7-bit data, so I'm not sure now whether what you wrote above applies to this code (then it's not a surprise that a code set to 7-bit works when you set the PC to 7-bits) or whether now you use 8-bits and no parity (as you should for a start)... This is all very confusing. If you have a scope, then you can easily verify what is the exact baudrate and whether it's wrong or acceptable. Do it first, then set the UART to 8N1 and try to make this work. As long as both ends work fine when set to the same format it's OK - if they _ALSO_ work when set differently, then just ignore that, as it doesn't matter.

[Glenn0010]

This is all very confusing. If you have a scope, then you can easily verify what is the exact baudrate and whether it's wrong or acceptable. Do it first, then set the UART to 8N1 and try to make this work. As long as both ends work fine when set to the same format it's OK - if they _ALSO_ work when set differently, then just ignore that, as it doesn't matter.

My apologies, I forgot to mention that I changed back to 8n1. So to reiterate, yesterday I check the uC TX and at 0x55 what I was receiving via the scope was correct, however on the uC end sometimes I'd receive 0x55 or 0xD5 which is why I am thinking it is a baud rate issue. I will hook up the scope and check it accurately.

Whenever I send a constant character from the uC  to the PC it is always received correctly. So I think when the uC is sampling the data, it is slightly off sometimes. So I'll check both TX and RX baud rates to see if I am off in any way.

Failing that, I'll try to use the external Oscillator as in my code currently I am using the internal one, and I am not calibrating it on startup which may be a problem.

I hope this clears things up

[kulky64]

If you are using Nucleo board you don't have to solder external XTAL with supporting components to the board. You can use 8MHz clock from ST-LINK.