Hello all, I am stuck in a rare issue I am having with a custom target (latest mbed-os) based on STM32F103VDT6. I have successfully developed an application using Mbed Studio using ARMC6 but to follow up I need to change to GCC_ARM as I need to use assembler libraries developed using gnu assembler.
With GCC compiles OK but the application hungs (nothing in the console).
I have rewrited a new very simple code for simplicity, here you are next.
Using GCC, the printf , thread_sleep_for(), even the call to myDelay doesn’t work, but If don´t use any of those, and use the for delay inline the code works and the led blinks.
I have created my TARGET_MYBOARD under the TARGET_STM32F103xE directory as the stm32f103xd and the stm32f103xe share the same cmsis library and I left the startup code and linker script under TOOLCHAIN_GCC_ARM with no modification.
Do you have any idea?
Thank you
#include "mbed.h"
#include <cstdint>
#define WAIT_TIME_MS 500
DigitalInOut ledYellow(PE_15,PIN_OUTPUT, OpenDrainNoPull, 1);
void myDelay(void)
{
for(int x = 0; x < 1000000; ++x)
{
x+=1;
x-=1;
}
}
int main()
{
while (true)
{
//printf("App running!\r\n");
ledYellow = 1;
//thread_sleep_for(WAIT_TIME_MS);
//myDelay();
for(int x = 0; x < 1000000; ++x)
{
x+=1;
x-=1;
}
ledYellow = 0;
//thread_sleep_for(WAIT_TIME_MS);
//myDelay();
for(int x = 0; x < 1000000; ++x)
{
x+=1;
x-=1;
}
}
}
If you use the debugger, what happens when it “doesn’t work”? Does it go to a fault handler, does it get stuck somewhere, etc?
Also, the fact that ThisThread::sleep_for() causes a problem makes me wonder if the RTOS is acting up. What if you link to mbed-baremetal instead of mbed-os in CMake?
it looks more like a clock problem. Which clock source are you using? The default is for Nucleo boards, which use external clock from the onboard STLink. For a XTAL, you need to override the clock_source setting.
It sounds like a wrong application’s entry point. In the TOOLCHAIN_GCC_ARM directory open the startup_stm32f103xd.S file and search for the main word. If you find
Regarding the issue with myDelay function it seems it is related to optimizations, the debugger jumps over the function as it were commented, changing x variable to volatile works as espexted
volatile int x;
void myDelay(void)
{
for(x = 0; x < 100000; ++x)
{
x+=1;
x-=1;
}
}
When a do a step into printf, degugger launch a Segmentation Fault:
Breakpoint 1, main () at .\main.cpp:24
24 {
Breakpoint 2, main () at .\main.cpp:27
27 printf("App running!\r\n");
Program
received signal SIGSEGV, Segmentation fault.
HardFault_Handler () at except.S:50
50 except.S: No such file or directory
Doing step into thread_sleep_for(WAIT_TIME_MS); degugger launched a Segmentation fault in the commented line:
void thread_sleep_for(uint32_t millisec)
{
auto d = duration<uint32_t, std::milli>(millisec);
#if MBED_CONF_RTOS_PRESENT
rtos::ThisThread::sleep_for(d);
#else
// Undocumented, but osDelay(UINT32_MAX) does actually sleep forever
mbed::internal::do_timed_sleep_relative_or_forever(d); // segmentation fault here
#endif
}
Breakpoint 1, main () at .\main.cpp:24
24 {
Program
received signal SIGSEGV, Segmentation fault.
HardFault_Handler () at except.S:50
50 except.S: No such file or directory.
You are welcome, Miguel. Yes, the Mbed CE seems very promising. Jamie, Johannes, Jan and all the other contributors did a very good job
Hello @jeromecoutant, it seems that some STM32 targets have wrong application’s entry point in the GCC_ARM startup files. Your precious support is essential . Thank you.
I am afraid I went too fast to call for victory, I think there should be something more wrong probably in same startup_stm32f103xe.S. With the Zoltan fix my simple application worked so my guess was my end application should do too but it is not. My procedure was to add chunks of software to my simple application to see where hungs, then debug, I have been able to add CAN, Mail, Thread, DigitalInOut and it looks no problem here but adding AnalogIn it hungs with a segmentation fault, here you are the debug message as long as the simple code, just to remember, this code works OK with ARMC6 and hungs with GCC_ARM.
Program
received signal SIGSEGV, Segmentation fault.
HardFault_Handler () at except.S:50
50 except.S: No such file or directory.
Hello all I have compared the startup code in mbed versus one generated with STM32CUBEIDE and are the same (but the bl main, replaced to bl _start) so the problem should not be there may be it is in the stm32f103xe.ld.
Finally I have everything working fine, really please to all of you,
The learning here is that may be is not a good idea to start a project if the ST mcu series don´t exists in the target, as it looks not easy stuff to deal with, at least for not advanced developers, another learning is the really smart people in this forum specially jerome with its black magic to finally solve this kind of problems in the proper way.
Another learning is that I see a near future problem particular for me as in February next year I need to take over a new project using a mature board in my company with an STM32F103VGT6 so I will race same problem as the mcu series is not ready in the repo so @jeromecoutant what is the proper way to request the creation of this mcu series?
. Thank you.