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.
Just to clarify, I think there is a slight confusion between the Blue Pills (STMF103-based boards) and Black Pills (STMF4x1-based boards). The first are notable for the high amount of counterfeit chips (some of which, surprisingly, can be identified because they implement some errata from the original). However, as far as my knowledge goes, there are no F4 counterfeits in the market (yet).
That said, I tried to run RTEMS (6) in a F401 in the past, but did not finish the project due to time constraints. Unfortunately in the meantime, I lost access to the project (my laptop was robbed), so I cannot provide the files. But anyway I might try this again in the short future.
Anyway, one advice that I give: The linker reconfiguration should be the first step, as with the debugger, its still possible to see what the board is doing (including the printf buffer), so changing the UART becomes much easier. Otherwise, the board will segfault before running any meaningful code.
Hi, I am experimenting with a Black Pill (STM32F401CE) and I got it to work (using USART_2).
Like you, I modified optenusart2.yml / optenusart3.yml (disabled USART_3 by changing to False, enabled USART_2 by changing it to true). Additionally, I changed the file optoschse.yml as my Black Pill has 25 MHz clock. Lastly, I changed the linker settings (in bsps/arm/stm32f4/start/linkcmds.stm32f4) to reflect the smaller RAM (96KB) and Flash (384KB).
I built the BSP manually then with ./waf configure --prefix=<RTEMS compiler path>, ./waf and ./waf install. To make sure the configurations are right, I checked the file 6/arm-rtems6/stm32f4/lib/include/bspopts.h to see if HSE and the USART was correct.
To run the application, I needed to apply a trick still, that I got from another post here in the forum. For the application to run with the debugger, first a .bin needs to be generated from the .exe (as mentioned in the post linked), then loaded with your tool of choice into the Blackpill, and only then the debugger can be run.
So comes the question, have you changed the HSE Clock as well? Normally the Black Pills have 25 MHz clock, safe some rare F411 with 8MHz. Those latter do not need modifications in the BSP with respect to clock, but the former for sure do.
This way the .yml files don’t need to be touched. But they are useful to know about the other settings. I want to test further the sysclk, enable I2C and so on later.
