STM32F302R8 USART Register does not match with Reference Manual - Page 1
Forum section: electronics / general

author: Glenn0010
author_rank: Regular Contributor
timestamp: May 14, 2019, 05:15:33 pm
content: 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

author: TK
author_rank: Super Contributor
timestamp: May 14, 2019, 07:14:26 pm
content: 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

author: lucazader
author_rank: Regular Contributor
timestamp: May 14, 2019, 07:21:19 pm
content: 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

author: Freddie Chopin
author_rank: Regular Contributor
timestamp: May 14, 2019, 07:41:00 pm
content: Check the very beginning of the chapter about USART in the reference manual.29.4. USART implementationTable 152. STM32F302xx USART featuresYour 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, thecomputed 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."

author: capt bullshot
author_rank: Super Contributor
timestamp: May 14, 2019, 07:46:52 pm
content: 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.

author: Freddie Chopin
author_rank: Regular Contributor
timestamp: May 14, 2019, 07:47:54 pm
content: Most of you did not experience this issue just because you did not use parity. Check my edited post above.

author: capt bullshot
author_rank: Super Contributor
timestamp: May 14, 2019, 07:51:11 pm
content: Quote from: Freddie Chopin on May 14, 2019, 07:47:54 pmYes, 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.

author: Glenn0010
author_rank: Regular Contributor
timestamp: May 15, 2019, 06:19:37 am
content: Quote from: TK on May 14, 2019, 07:14:26 pmTo 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

author: Glenn0010
author_rank: Regular Contributor
timestamp: May 15, 2019, 06:20:10 am
content: Quote from: blueskull on May 14, 2019, 07:17:55 pmHave you had similar experiences in the past?

author: Glenn0010
author_rank: Regular Contributor
timestamp: May 15, 2019, 06:23:02 am
content: Quote from: lucazader on May 14, 2019, 07:21:19 pmI 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.

author: Glenn0010
author_rank: Regular Contributor
timestamp: May 15, 2019, 06:32:06 am
content: Quote from: Freddie Chopin on May 14, 2019, 07:41:00 pmHi 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

author: Freddie Chopin
author_rank: Regular Contributor
timestamp: May 15, 2019, 07:10:39 am
content: 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.

author: Glenn0010
author_rank: Regular Contributor
timestamp: May 15, 2019, 07:20:33 am
content: Quote from: Freddie Chopin on May 15, 2019, 07:10:39 amI 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

author: Freddie Chopin
author_rank: Regular Contributor
timestamp: May 15, 2019, 07:54:05 am
content: Quote from: Glenn0010 on May 15, 2019, 07:20:33 amIt could. Do you have a scope or a logic analyzer?

author: techman-001
author_rank: Frequent Contributor
timestamp: May 15, 2019, 10:54:22 am
content: Quote from: Freddie Chopin on May 15, 2019, 07:10:39 amActually 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

author: Glenn0010
author_rank: Regular Contributor
timestamp: May 15, 2019, 11:51:52 am
content: Quote from: techman-001 on May 15, 2019, 10:54:22 amInteresting, 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

author: techman-001
author_rank: Frequent Contributor
timestamp: May 15, 2019, 12:03:32 pm
content: Quote from: Glenn0010 on May 15, 2019, 11:51:52 amI'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.

author: Glenn0010
author_rank: Regular Contributor
timestamp: May 15, 2019, 03:22:13 pm
content: Quote from: Freddie Chopin on May 15, 2019, 07:54:05 amI 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.

author: Freddie Chopin
author_rank: Regular Contributor
timestamp: May 15, 2019, 04:25:55 pm
content: Quote from: Glenn0010 on May 15, 2019, 03:22:13 pmNo, 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 (;

author: Glenn0010
author_rank: Regular Contributor
timestamp: May 15, 2019, 09:15:43 pm
content: Quote from: Freddie Chopin on May 15, 2019, 04:25:55 pmSo 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://------------------------------------ UART Enable -------------------------------------RCC->APB1ENR |= RCC_APB1ENR_USART2EN; // Enabling USART2 ClockRCC->AHBENR |= RCC_AHBENR_GPIOAEN; // Enabling Port AGPIOA->MODER |= GPIO_MODER_MODER2_1 | GPIO_MODER_MODER3_1; // Setting PA2, PA3 as alternate function modeGPIOA->PUPDR |= GPIO_PUPDR_PUPDR2_0 | GPIO_PUPDR_PUPDR3_0; // Setting PA2, PA3 as pull ups.GPIOA->AFR = 0x7700; // Alternate Functions USART 2 For PA2, PA3USART2->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 EnableUSART1->CR3 = (USART1->CR3 & 0xFFFFFCFF);USART1->CR2 = (USART1->CR2 & ~USART_CR2_STOP); // 1 stop bitUSART2->BRR = pckl1f/9600; // 32MHz / 9600USART2->CR1 |= USART_CR1_UE; // Uart EnableNVIC_EnableIRQ(USART2_IRQn); // Enabling USART2 interruptAnd here is my ISRCode: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.

author: Freddie Chopin
author_rank: Regular Contributor
timestamp: May 16, 2019, 07:27:18 am
content: 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.

author: Glenn0010
author_rank: Regular Contributor
timestamp: May 16, 2019, 07:50:06 pm
content: Quote from: Freddie Chopin on May 16, 2019, 07:27:18 amSo 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 XTALAny thoughts?

author: Freddie Chopin
author_rank: Regular Contributor
timestamp: May 16, 2019, 08:32:38 pm
content: 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%...QuoteNo - 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?QuoteAs 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.

author: Glenn0010
author_rank: Regular Contributor
timestamp: May 17, 2019, 08:26:37 am
content: Quote from: Freddie Chopin on May 16, 2019, 08:32:38 pmMy 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

author: kulky64
author_rank: Regular Contributor
timestamp: May 17, 2019, 01:10:24 pm
content: 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.

author: Glenn0010
author_rank: Regular Contributor
timestamp: May 17, 2019, 01:32:40 pm
content: Quote from: kulky64 on May 17, 2019, 01:10:24 pmArgh that did not come in my mind. I've already moved solder bridges around and put on a 16MHz XTAL so I'll just do that now

author: Glenn0010
author_rank: Regular Contributor
timestamp: May 17, 2019, 01:36:46 pm
content: So I've had a look at my scope and here are the results.The RX line i.e. PC baud rate, exactly 9600:The TX line i.e. uC baud rate, 8928.57 = 7% error:Therefore the uC baud rate is obviously off. I will change to the external XTAL and update you. Thanks everyone for your help!

author: Glenn0010
author_rank: Regular Contributor
timestamp: May 19, 2019, 02:35:03 pm
content: So I have been trying to get the UART to work for a while and after looking at the lines with scope, I discovered the the uart is twice the Baud rate I programmed it to and I don't know why.So I am running my uC of a 16MHz external crystal dividing that by 2 to get 8MHz at PLL input. Multiplying that by 9 to get 72MHz SYSCLK and then dividing that by 2 to get 36MHz APB1 clock which is the maximum.After I do this I stole a function from the STDPherif Libraries to check that the clocks are indeed what I set them to and they are correct PCLK1 is 36MHz.With the R8, the USART 2 clock source can only be PCLK1 as indicated by the datasheet and it cannot be changed.Hence then I set my Baud rate by plugging in the following into the BRR register. 36000000/9600. However the baud rate comes out twice as fast.So that means either:1 - APB1 is running off 72MHz which is outside is spec2 - The clock source for the UART2 is being used as the SYSCLKHere is the code:Code:/*---------------------------------------------------------------------------------------------------------------12/5/2019SysCroeClock = 64MhzBlinkyADC scaninng 2 channels continously in DMA Mode 1.5 conversiion cycles at 64MhzUART2 with interrupt running on clock of 32MHz at 9600 baud---------------------------------------------------------------------------------------------------------------*/#include "stm32f302x8.h"//----------------- Gloobal Variables -------------------------------------------------------------------------uint16_t ADC_Samples = {0,0};void Delay (uint32_t nTime);uint16_t ADC1ConvertedValue = 0;uint16_t ADC1ConvertedVoltage = 0;int calibration_value = 0;volatile uint32_t TimingDelay = 0;int x =0;intCoreClock = 0;static __I uint8_t APBAHBPrescTable = {0, 0, 0, 0, 1, 2, 3, 4, 1, 2, 3, 4, 6, 7, 8, 9};uint32_t tmp = 0, presc = 0;uint32_t hcklf = 0, pckl1f= 0;int init (){//---------------------- RCC Clock Initalization ------------------------------------------------------------------RCC->CR |= RCC_CR_HSEON; //HSE onwhile((RCC->CR & RCC_CR_HSERDY) != RCC_CR_HSERDY); // Waiting for HSE to be readyRCC->CR &= ~RCC_CR_PLLON; // Disable PLLwhile((RCC->CR & RCC_CR_PLLRDY)== RCC_CR_PLLRDY); // Wait for pll to turn offRCC->CFGR2 = RCC_CFGR2_PREDIV_DIV2;RCC->CFGR = RCC_CFGR_PLLSRC_HSE_PREDIV | RCC_CFGR_PLLMUL9 | RCC_CFGR_HPRE_DIV1 | RCC_CFGR_PPRE1_DIV2 ;//PLLSCR = HSE/2 , PLLMUL = x9 (72Mhz),AHB prescaler not devided, APB1 Clock /2 = 36MHz (Max=36MHz)RCC->CR |= 0x01000000; // Turn on PLL onwhile((RCC->CR & RCC_CR_PLLRDY) != RCC_CR_PLLRDY); // Waiting for PLL to be readyFLASH->ACR |= FLASH_ACR_LATENCY_1; // Adjust flash speed for new frequencyRCC->CFGR |= RCC_CFGR_SW_1; // Set PLL as system clockwhile((RCC->CFGR & RCC_CFGR_SWS_1) != RCC_CFGR_SWS_1); // Wait fpr pll to be used as syste, clock//---------------------- Blinky Initialization ----------------------------------------------------------------RCC->AHBENR |= (1<<18); //Enabling AHB GPIOBGPIOB->MODER |= 0x00000010; // PB2 OutputGPIOB->OSPEEDR |= 0x0; // Low speed output on all of port BGPIOB->PUPDR |= 0x30; // PB2 pull down//----------------------- Checking System Clock ---------------------------------------------------------------SystemCoreClockUpdate(); // Calculating new system clockCoreClock = SystemCoreClock;tmp = RCC->CFGR & RCC_CFGR_HPRE;tmp = tmp >> 4;presc = APBAHBPrescTable;/* HCLK clock frequency */hcklf = CoreClock >> presc;tmp = RCC->CFGR & RCC_CFGR_PPRE1;;tmp = tmp >> 8;presc = APBAHBPrescTable;/* PCLK1 clock frequency */pckl1f = hcklf >> presc;/*while (CoreClock != 72000000) // Error Handling{GPIOB->BSRR = (1<<2) ;}*///------------------------------------ UART Enable -------------------------------------RCC->APB1ENR |= RCC_APB1ENR_USART2EN; // Enabling USART2 ClockRCC->AHBENR |= RCC_AHBENR_GPIOAEN; // Enabling Port AGPIOA->MODER |= GPIO_MODER_MODER2_1 | GPIO_MODER_MODER3_1; // Setting PA2, PA3 as alternate function modeGPIOA->AFR = 0x7700; // Alternate Functions USART 2 For PA2, PA3USART2->CR1 &= ~USART_CR1_M;USART2->BRR = pckl1f/9600; // 36MHz / 9600USART2->CR2 = 0x0;USART2->CR1 |= USART_CR1_UE ;USART2->CR1 |= USART_CR1_TE | USART_CR1_RE | USART_CR1_RXNEIE;NVIC_EnableIRQ(USART2_IRQn); // Enabling USART2 interruptreturn(0);}int main(){init();while (1){GPIOB->BSRR = (1<<2) ;for ( x = 0; x<500000; x++){}GPIOB->BSRR = (1<<(2+16));for ( x = 0; x<500000; x++){}USART2->TDR = 0x55;while (!(USART2->ISR & USART_ISR_TC)){};}}void USART2_IRQHandler(void){if(USART2->ISR & USART_ISR_RXNE){char temp = USART2->RDR;USART2->TDR = 0x55;while (!(USART2->ISR & USART_ISR_TC)){};}}Really appreciate any help

author: Freddie Chopin
author_rank: Regular Contributor
timestamp: May 19, 2019, 03:29:05 pm
content: Start with small steps. For example, as a first iteration, don't configure any system clock at all - you should then be running of a HSI 8MHz. Configure USART to this clock and see with the scope whether the baudrate is more-or-less correct. Then just set your clock to HSE, configure UART properly and see whether the baudrate is what you expect. Then maybe enable APB divider by 2 and repeat. Then set PREDIV/2. Then enable PLL, as the last step.SystemCoreClockUpdate() proves nothing, as it requires proper global definition of HSE_VALUE - do you have it set to 16000000? Please also note that SystemCoreClock is the HCLK, so your calculation of HCLK from this value are actually redundant and correct only because there is no divider. I would just ignore this function, as using it in your code adds just another unknown variable to the whole picture.One step at a time and you will have it sorted within an hour.BTW - are you sure there is no code in your project which does automatic clock configuration, which would - for example - set USART2 clock to SYSCLK? Startup codes which come from ST usually call a function called SystemInit() which actually does set the clock...If you have a debugger, post the values of RCC and USART2 registers.

author: Glenn0010
author_rank: Regular Contributor
timestamp: May 19, 2019, 04:30:07 pm
content: Quote from: Freddie Chopin on May 19, 2019, 03:29:05 pmI did update the HSE_VALUE to reflect what I have but that did not fix it.However I did as you said, started working my way backwards and found the mistake. I had it was in line 44 and 43. I removed the CFGR 2 line and added the following to line 44 | RCC_CFGR_PLLXTPRE_HSE_PREDIV_DIV2. That was my main issue.I also had another little mistake in the last while loop of the RCC Init but that was not the issue.I was setting CFGR2 as the pre div inas seen below, as it says it is the same as CFGR, however when I set CFGR1 instead and removed the statement of CFGR2 it all worked well. A bit confusing but figured it out now thanks to your help.Edit: On second thought I had tried the PLLXTPRE thing before and it didin't work so I think it was the change in definition and putting PLLXTPRE in again together

author: Freddie Chopin
author_rank: Regular Contributor
timestamp: May 19, 2019, 04:57:15 pm
content: QuoteThis is because the first bit of CFGR2 and the bit in CFGR are really just one and the same bit. Therefore here you set this one-and-the-same-bit:RCC->CFGR2 = RCC_CFGR2_PREDIV_DIV2;And in the next line you clear it back to zero:RCC->CFGR = RCC_CFGR_PLLSRC_HSE_PREDIV | RCC_CFGR_PLLMUL9 | RCC_CFGR_HPRE_DIV1 | RCC_CFGR_PPRE1_DIV2 ;//PLLSCR = HSE/2 , PLLMUL = x9 (72Mhz),AHBIt would be OK if you would first set CFGR and only then modify CFGR2.

author: Glenn0010
author_rank: Regular Contributor
timestamp: May 20, 2019, 06:27:45 pm
content: Quote from: Freddie Chopin on May 19, 2019, 04:57:15 pmThanks so much for your continued help