cancel
Showing results for 
Search instead for 
Did you mean: 

Built in USART functions putting incorrect values into registers

melissarosegarden
Associate
Posted on February 13, 2014 at 20:30

Hello, I am working on the STM32F429 with Keil uVision version 5, and am trying to get the USART1 module working. In attempting to use the functions provided in the stm32f4xx USART library files, I am getting very odd behavior, specifically values being put into the registers that shouldn't be getting put into them. I can manually set the registers in order to get the USART module working, but am curious as to the reason behind this behavior. Following is my transcribing of the issues happening:

--------------------------------------------------------------------------

Function call: USART_ClockInit:

CR2 starting value: 0x000

1.) tmpreg = 0x000

2.) ~0x0F00, Result: 0xF0FF

3.) tmpreg &= 0xF0FF, Result: 0x0000

4.) tmpreg |= Possible values: (0x0800/0x0400/0x0200/0x0100), Current value: 0x0000

5.) CR2 = tmpreg (0x0000)

Final result of CR2: 0x0040

--------------------------------------------------------------------------

Function call: USART_Init:

CR2 Initialization section:

CR2 Starting Value: 0x0040

1.) tmpreg = 0x0040

2.) ~0x3000, Result: 0xCFFF

3.) tmpreg &= 0xCFFF, Result: 0x0040

4.) tmpreg |= Possible values: (0x0000/0x1000/0x2000/0x3000), Current value: 0x0000

5.) CR2 = tmpreg (0x0040)

Final result of CR2: 0x0840

--------------------------------------------------------------------------

CR1 Initialization section:

CR1 Starting Value: 0x0000

1.) tmpreg = 0x0000

2.) ~0x160C, Result: 0xE9F3

3.) tmpreg &= 0xE9F3, Result: 0x0000

4.) tmpreg |= Possible values: (0x1000/0x0400/0x0600/0x0004/0x0008), Current value: 0x000C

5.) CR1 = tmpreg (0x000C)

Final result CR1: 0x09DD

--------------------------------------------------------------------------

CR3 Initialization section:

CR3 Starting Value: 0x0000

1.) tmpreg = 0x0000

2.) ~0x0300, Result: 0xFCFF

3.) tmpreg &= 0xFCFF, Result: 0x0000

4.) tmpreg |= Possible values: (0x0100/0x0200/0x0300), Current value: 0x0000

5.) C3 = tmpreg (0x0000)

Final Result CR3: 0x0431

--------------------------------------------------------------------------

BRR setting:

A set of math to create a floating value out of a int am not going to transcribe, final result is: 0x0000. 

--------------------------------------------------------------------------

Again, I can use manually determine the correct register values and set them, but that gets tedious over time and is error prone, and don't want to write my own library functions to do it for me, so if I could get the given ones working that would be great. 
4 REPLIES 4
Posted on February 13, 2014 at 20:59

Not having any problems with the F429, and ST Library here, using uv4

Don't really understand what your issue is, of if it relates to how the debugger is interacting with the registers.
Tips, Buy me a coffee, or three.. PayPal Venmo
Up vote any posts that you find helpful, it shows what's working..
melissarosegarden
Associate
Posted on February 13, 2014 at 22:02

Well, the end values in the register (see final value/step 5 for the discrepancy on most of them) just don't correspond to what should be getting set. I might try rolling back to version 4 from version 5 and seeing if that helps (I am on uVision4 as well, but version 5.1). I agree that it might be a debugger issue, but my testing with my system outside of the debugger has not worked either.

Posted on February 13, 2014 at 22:46

Perhaps you're doing something else wrong in the initialization or setup, I don't have any context to work with.

You could use the SWV interface and output register content post USART_Init() rather than single-step through it. For an async connection you shouldn't have to configure with USART_ClockInit()

Tips, Buy me a coffee, or three.. PayPal Venmo
Up vote any posts that you find helpful, it shows what's working..
jpeacock2399
Associate II
Posted on February 14, 2014 at 00:36

I have no problems with the library functions, so either you have a bug in your parameters or there's a problem with your IDE.  Remember you are accessing hardware registers, not variables in RAM.  The results can be affected by what happens in the USART.

Try single stepping through a call and look at your variables.

  Jack Peacock