USART Problems

tylerd · ‎2008-11-04

Posted on November 04, 2008 at 11:24

USART Problems

tylerd · ‎2011-05-17

Posted on May 17, 2011 at 12:50

I'm pretty new at coding for the ARM processor, but I seem to be having trouble implementing a basic non-interrupting USART communication with Hyperterminal. Basic meaning I have a probe hooked up to the micro-controller's TX pin, and I'm not seeing anything signal on it.

I'm using IAR's Embedded Workbench as my compiler and debugger, via j-link, and I've gotten code to run, which makes an LED to blink on the dev board, so I know it's running actual code. I've tried to get some of the ST USART examples to run, but they're running in ''thumb'' mode, and I can't seem to run it in ARM mode, so I just looked at what code they used specifically for USART.

The interesting thing is that when I'm using the j-link, I'm able to see what registers have certain values on them. I've watched the GPIO to see if it initializes correctly (it does), but when I watch the control registers pertaining to USART1, nothing changes on them, even when I'm just loading the default values in the Init Structure, then initializing and enabling the USART.

Sorry about the novel, but any tips? Thanks in advance.

andreas2 · ‎2011-05-17

Posted on May 17, 2011 at 12:50

Have you enabled the USART1 clock?

st3 · ‎2011-05-17

Posted on May 17, 2011 at 12:50

Quote:

I can't seem to run it in ARM mode

The STM32 - and any other Cortex-M3 - doesn't do ARM mode...

Does it? :-?

[ This message was edited by: st7 on 01-11-2008 23:32 ]

tylerd · ‎2011-05-17

Posted on May 17, 2011 at 12:50

Just checking in. I looked at the USART clock to see if it was enabled. It was on the default disabled, so I changed it, but it still doesn't produce any results. Right now I'm looking again at the setup functions, and using the ''watch'' feature in the debug workbench software, and it still doesn't look like the functions are working correctly.

There is a line of code after the function gets done setting the preferences (e.g. mode, stop bits):

USARTx->CR2 = (u16)tmpreg;

In this case tmpreg has a value of 0x0000C8DF. tmpreg is cast as u16 but the CR2 register in USART1 and USARTx stay at the value 0xf8DF. I even tested changing the function to only write 0x1111, but it still doesn't work. I'm wondering if the register is write-protected somehow and if I need to flip a bit somewhere do I can write to those registers.

Thanks!

(edit: fixed the line of original code)

[ This message was edited by: tylerd on 03-11-2008 18:26 ]

tylerd · ‎2011-05-17

Posted on May 17, 2011 at 12:50

Yeah, that helped. The solution was really stupid, I just needed to add the peripheral .c files to the project, not just include the .h files. But I have no problem using it now. Thanks a lot!

tylerd · ‎2011-05-17

Posted on May 17, 2011 at 12:50

I also noticed that most of the ST example codes will not compile and link without me adding a few lines of code. I'm not sure if the .h and .c files are in the wrong directory (I don't think so; I made many copies in the directories around where my main.c is), but I have to explicitly add

#include ''stm32f10x_usart.h''

#include ''stm32f10x_usart.c''

as well as USART_TypeDef* USART1; even though the program uses other peripherals, like GPIO, NVIC or TIM1, and they don't need to have a TypeDef created specifically in main.c for them. This is in addition to the stm32f10x_lib.h which calls all of the peripheral .h files if they're needed.

I'm not really sure what's going on here, but I think it might be part of the problem. I'm trying to be as concise as possible, but if I need to clarify further, I will.

Thanks!

andreas2 · ‎2011-05-17

Posted on May 17, 2011 at 12:50

You shouldn't include any file but stm32f10x_lib.h, and absolutely not any c-files. You have some problem with your build system and you need to get that fixed before even trying to do something about the USART problem (if it still exists).

There should be a per-project stm32f10x_conf.h somewhere. To enable the inclusion of a peripheral header file from stm32f10x_lib.h you have to define a specific symbol in the conf file. It should be done in the example projects already, but make sure the correct one is used (check include search paths).

I don't know why they designed it this way, there's no obvious reason to me why you wouldn't want all peripherals' library code declared at all times. There's no runtime overhead.