Success with ARMC6, failure with GCC_ARM

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

myboard

#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

bl main

replace it with

bl _start

1 Like

Hello here you are the debugging results:

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.

RIGHT TO THE POINT!!!, excellent Zoltan, brilliant, you saved my life, I have no words to thank you.

Now I´ll move my custom target to Mbed-CE which I find it super interesting.

1 Like

You are welcome, Miguel. Yes, the Mbed CE seems very promising. Jamie, Johannes, Jan and all the other contributors did a very good job :heart_eyes:

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 :wink: . Thank you.

Hi

it seems that some STM32 targets have wrong application’s entry point in the GCC_ARM startup files

Bad luck…

$ find targets/TARGET_STM/ -name “startup*.S” | xargs grep “bl main”
targets/TARGET_STM/TARGET_STM32F1/TARGET_STM32F103xE/TOOLCHAIN_GCC_ARM/startup_stm32f103xe.S: bl main

1 among 146 files :frowning:
You can propose a patch!

Thx

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.

#include <mbed.h>
#include <cstdint>

#define WAIT_TIME_MS 1000 

AnalogIn vOffSet(PA_6);

int main()
{
    while(true)
    {
        printf("Mbed OS %d.%d.%d.\n", MBED_MAJOR_VERSION, MBED_MINOR_VERSION, MBED_PATCH_VERSION);

        thread_sleep_for(WAIT_TIME_MS); 
    }   
}

The target definition in targets.json

	"MYBOARD": {
        "inherits": [
            "MCU_STM32F103xE"
        ],
		"mbed_rom_start": "0x08000000",
        "mbed_rom_size": "0x80000",
        "mbed_ram_start": "0x20000000",
        "mbed_ram_size": "0x10000",
        "device_name": "STM32F103xE",
		"macros_add": [
            "HSE_VALUE=16000000"
		],
        "overrides": {
            "clock_source": "USE_PLL_HSE_XTAL",
            "lse_available": 0
        }
    }        	

Jerome it is possible any more error in the startup code?

Thank you very much.

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.

I just pushed STM32F1: add MCU_STM32F103xD and MCU_STM32F103xG support by jeromecoutant · Pull Request #15356 · ARMmbed/mbed-os · GitHub

1 Like

Jerome that is great!! the clean and convenient solution, I am really pleased.
Is there any way I can get it or should I wait until merged?

Thank you very much.

It is possible to clone a specific commit or PR.
Just try

git clone https://github.com/ARMmbed/mbed-os
cd mbed-os
git pull origin pull/15356/head

then you will see

remote: Enumerating objects: 35, done.
remote: Counting objects: 100% (35/35), done.
remote: Compressing objects: 100% (13/13), done.
remote: Total 28 (delta 15), reused 27 (delta 15), pack-reused 0
Unpacking objects: 100% (28/28), 10.78 KiB | 81.00 KiB/s, done.
From https://github.com/ARMmbed/mbed-os
 * branch                  refs/pull/15356/head -> FETCH_HEAD
Updating da7c0b7d3d..94773af7d9
Fast-forward
 targets/TARGET_STM/TARGET_STM32F1/CMakeLists.txt   |   1 +
 .../TARGET_STM32F103xD/CMakeLists.txt              |  26 ++
 .../TARGET_STM32F103xD/PeripheralNames.h           |  90 ++++
 .../TOOLCHAIN_ARM/startup_stm32f103xe.S            | 312 +++++++++++++
 .../TOOLCHAIN_ARM/stm32f103xd.sct                  |  57 +++
 .../TOOLCHAIN_GCC_ARM/startup_stm32f103xe.S        | 466 +++++++++++++++++++
 .../TOOLCHAIN_GCC_ARM/stm32f103xd.ld               | 203 +++++++++
 .../TOOLCHAIN_IAR/startup_stm32f103xe.S            | 498 +++++++++++++++++++++
 .../TOOLCHAIN_IAR/stm32f103xd.icf                  |  59 +++
 .../TARGET_STM32F1/TARGET_STM32F103xD/cmsis_nvic.h |  39 ++
 .../TOOLCHAIN_ARM/startup_stm32f103xe.S            |  26 +-
 .../TOOLCHAIN_GCC_ARM/startup_stm32f103xe.S        |   6 +-
 targets/targets.json                               |  12 +
 13 files changed, 1767 insertions(+), 28 deletions(-)
 create mode 100644 targets/TARGET_STM/TARGET_STM32F1/TARGET_STM32F103xD/CMakeLists.txt
 create mode 100644 targets/TARGET_STM/TARGET_STM32F1/TARGET_STM32F103xD/PeripheralNames.h
 create mode 100644 targets/TARGET_STM/TARGET_STM32F1/TARGET_STM32F103xD/TOOLCHAIN_ARM/startup_stm32f103xe.S
 create mode 100644 targets/TARGET_STM/TARGET_STM32F1/TARGET_STM32F103xD/TOOLCHAIN_ARM/stm32f103xd.sct
 create mode 100644 targets/TARGET_STM/TARGET_STM32F1/TARGET_STM32F103xD/TOOLCHAIN_GCC_ARM/startup_stm32f103xe.S
 create mode 100644 targets/TARGET_STM/TARGET_STM32F1/TARGET_STM32F103xD/TOOLCHAIN_GCC_ARM/stm32f103xd.ld
 create mode 100644 targets/TARGET_STM/TARGET_STM32F1/TARGET_STM32F103xD/TOOLCHAIN_IAR/startup_stm32f103xe.S
 create mode 100644 targets/TARGET_STM/TARGET_STM32F1/TARGET_STM32F103xD/TOOLCHAIN_IAR/stm32f103xd.icf
 create mode 100644 targets/TARGET_STM/TARGET_STM32F1/TARGET_STM32F103xD/cmsis_nvic.h

BR, Jan

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 again for you great help.

I have updated the PR with this new device

Excellent!! counting on that I don´t see any risk, thank you very much for your priceless help.