I’m currently experimenting with the STM32F4 BSP on an STM32F411CE board and attempting to get the console output working. I’m running the following simple hello world example:
/*
* Hello world example
*/
#include <rtems.h>
#include <stdlib.h>
#include <stdio.h>
#include <unistd.h>
rtems_task Init(rtems_task_argument ignored)
{
while (1) {
printf("\nHello World\n");
sleep(1);
}
exit(0);
}
However, I’m not seeing any output on any USART port. I attached GDB and captured a backtrace (attached as backtrace_1.png). The program seems to be stuck here in usart.c.
Upon further inspection, it appears that RTEMS is configured to use USART3 by default, which isn’t available on the STM32F411CE. To address this, I enabled USART1 by setting enabled: true in optenusart1.yml and set it to false in optenusart3.yml.
Despite this change, I still couldn’t get any output. The system now seems to hang at this point:
I’ve attached the corresponding backtrace as backtrace_2.png.
There was a bit of conversation off line but…
Your board, by using USART1, needs to enable the pins that are connected to USART1 (or else the clock signals won’t be started for those pins and nothing will happen).
So, in the BSP, not only do you have to tell it to put the console on USART1, but also to enable pins PA9 and PA10.
For the uninvolved in the audience that are following along, the 'F411CE processor is commonly loaded onto a dev board called a “Black Pill”. These are negligible cost boards from China. Small, cheap, with very few features. But the big issue is that the processors may or may not be parts made by ST Microelectronics. The popular “Blue Pill” board is known for having clone processors loaded, some good clones, some bad clones. The Black Pill boards are no different, they may have STM32F411 processors or they could be something different, just marked as the STM32 part.
When you are chasing down issues with these boards, keep in mind that your code may not be the problem.
In this case, the OP said that they had UART1 working when they used STM32CubeIDE. That’s a good sign and it’s likely just a matter of enabling the uart pins.
I think that should be all that is necessary.
The F411 processor is very close to the F407 processor that is the basis of the STM32F4 BSP, but has less FLASH and RAM, so you’ll have to alter the linker files appropriately.
If you were to use an F7 processor, the uarts have a slightly different register structure and that would have to be accommodated in usart_write_polled.
I tried usart1 by setting enabled: true in optenusart1.yml and enabled: false in optenusart3.yml. But then I got the backtrace_2, which is present in the attachment of original post (left image).
Is there anything else I will have to do to enable the clock on the specific gpio or bsp is supposed to take care of that?
After making changes to config.ini. It is advisable to run ./waf distclean and rebuild BSP and do not forget to run ./waf install. Do the same in your custom application.
