FreeRTOS Support Archive
The FreeRTOS support forum is used to obtain active support directly from Real
Time Engineers Ltd. In return for using our top quality software and services for
free, we request you play fair and do your bit to help others too! Sign up
to receive notifications of new support topics then help where you can.
This is a read only archive of threads posted to the FreeRTOS support forum.
The archive is updated every week, so will not always contain the very latest posts.
Use these archive pages to search previous posts. Use the Live FreeRTOS Forum
link to reply to a post, or start a new support thread.
[FreeRTOS Home] [Live FreeRTOS Forum] [FAQ] [Archive Top] [October 2010 Threads] Error in STM32_USART.cPosted by Al Williams on October 27, 2010 I recently ported FreeRTOS to an STM32 target board and started with the CORTEX_STM32F103_GCC_Rowley demo. There are a number of small issues there if you try to use the new device library, etc. However, the USART driver has some serious problems. I'd assume no one has actually tried to use the second serial port on the demo. The biggest issue is the init code has: RCC_APB2PeriphClockCmd( RCC_APB1Periph_USART2 | RCC_APB2Periph_GPIOA, ENABLE );
This should be: RCC_APB1PeriphClockCmd( RCC_APB1Periph_USART2 , ENABLE ); RCC_APB1PeriphClockCmd( RCC_APB2Periph_AFIO , ENABLE );
The way the code is set up, the AFIO vs GPIO error is harmless, but still wrong. But USART2 never gets lit up using the exisiting driver. A few other things. The driver turns on DMA for both USARTs but doesn't configure it. This seems to be harmless, but is unnecessary. And the IRQ for USART2 is empty! It is easy to copy the USART1 ISR or -- what I did -- factor it out and make both IRQs call the worker function. Al W
RE: Error in STM32_USART.cPosted by Richard on October 28, 2010 Is this because the libraries and/or device has changed since the demo was written, or would it always have been wrong.
The UART drivers are just part of the demo, rather than FreeRTOS itself, so I don't really want a bug tracker opened for this point - but I would be grateful if you could add this information into a change request tracker so it doesn't get lost. Thanks.
Regards.
RE: Error in STM32_USART.cPosted by Al Williams on October 28, 2010 Hi Richard,
Yeah I understand it isn't actually part of the OS but I thought it might help someone. It looks like it is JUST in the Rowley demo (I don't see the file STM32_USART.c in any other STM port). There are some changes I made due to the different library version but I didn't mention those. The changes I mentioned above are just arbitrarily wrong. The USART2 is never turned on. There is no reason to turn DMA on for the ports (that I know of). And the USART2 ISR being missing is just incorrect. It looks to me like someone decided to add DMA and port2 to a working piece of code and then stopped in the middle.
I'll open a CR tracker for it. I contributed an LPC port some time back (http://www.drdobbs.com/blog/archives/2010/08/embedded_operat.html) and would be glad to contribute this one (although keep in mind that I have mutated it so it is no longer Rowley-dependent, uses the current STM Libs, has a different Startup etc.
Thanks
Copyright (C) Amazon Web Services, Inc. or its affiliates. All rights reserved.
|