[SOLVED] Can not compile or run embos on stm32f103rbt6

ali_asadzadeh · Jan 8th 2024, 10:38am

Hi
I have setup a simple project to test embos with stm32f103rbt device, I just used the default settings, after changing the default complier warnings to MISRA compatible and changed the C standard to C99 and C++ to C++11 most of the errors would go away, But still there is two errors

Source Code

.\Objects\marlin.axf: Error: L6218E: Undefined symbol Stack_Mem (referred from os_initsysstackinfo.o).
.\Objects\marlin.axf: Error: L6218E: Undefined symbol __initial_sp (referred from os_initsysstackinfo.o).

So after searching I think I should make these symbols exported in the startup assembly file, So I tried to use these lines in the startup assembly file like this

Source Code

Stack_Size EQU 0x00000400
; EXPORT the Stack_Mem and __initial_sp symbols for use in C files
EXPORT Stack_Mem
EXPORT __initial_sp

But it would generate an error like this

Display Spoiler

another solution would be to comment these lines

C Source Code

OS_SysStackBaseAddr = (unsigned long) &Stack_Mem;
OS_SysStackSize = (unsigned int) ((unsigned long)&__initial_sp - (unsigned long)&Stack_Mem);
OS_SysStackLimit = (unsigned long) &__initial_sp;

in the OS_InitSysStackInfo function, Now the project would be build and when I try to debug it it would crash, so How should I test this os?

SEGGER - Martin · Jan 8th 2024, 11:12am

Dear Ali Asadzadeh,

Thanks for your inquiry.

I assume you are following our Wiki page on creating CMSIS-based projects with embOS?
In that case, adding the EXPORT directives you have mentioned to the start-up file is the correct solution to the observed problem, as mentioned in the Wiki.

Please note that modification to OS_InitSysStackInfo.c is not a proper solution, since embOS will use the variables that are initialized therein for debug purposes.
By commenting out their initialization, embOS will effectively assume the System Stack to be located a address 0x00, which will result in memory faults when embOS writes an initial pattern byte to that address.

embOS does require the symbols __initial_sp and Stack_Mem to be accessible from C-Code, hence adding them to the start-up file is required when these symbols are not exported by default.

.\Objects\marlin.axf: error: L6002U: Could not open file .\objects\startup_stm32f10x_md.o: No such file or directory

This indicates that startup_stm32f10x_md.s was not correctly build after adding the EXPORT directives.
Can you please confirm it builds properly with your project?

Also, embOS for Cortex-M and Keil MDK comes with various sample projects for different evaluation boards, and these projects' start-up files of course include the required export directives already.
You could use one of those as a template, e.g. startup_stm32f10x_hd.s contained in our shipped start project for the STM3210E-Eval board (the projects are available for evaluation and may be retrieved from our website).

Does that solve the observed issue?
Please let me know if I can be of any further help.

Best regards,
Martin

ali_asadzadeh · Jan 9th 2024, 1:34pm

Dear Martin Hi,
Thanks for the update, I have used the default keil startup file

Adding the EXPORT Stack_Mem and EXPORT __initial_sp would generate some errors, Now I have uncommented the c code required for embos to it's original state like this

C Source Code

OS_SysStackBaseAddr = (unsigned long) &Stack_Mem;
OS_SysStackSize = (unsigned int) ((unsigned long)&__initial_sp - (unsigned long)&Stack_Mem);
OS_SysStackLimit = (unsigned long) &__initial_sp;

and I have replaced the startup file content with the STM3210E-Eval board link that you have sent,

And Now instead of 2 errors requiring Stack_Mem and __initial_sp to be exported, I would only get one error

and if I add the these lines in the beginning of the project

Source Code

EXPORT Stack_Mem
EXPORT __initial_sp
EXPORT Stack_Size
EXPORT Stack_Limit

I would get another new error like this

keil wrote:

.\Objects\marlin.axf: Error: L6915E: Library reports error: Conflicting stack/heap set up methods in use. __user_setup_stackheap, __user_initial_stackheap cannot be used with __initial_sp, __heap_base and __heap_limit

So what should I do? you can check out the sample project and see the errors for yourself.

ali_asadzadeh · Jan 9th 2024, 1:40pm

Also Please note that my keil version is 5.38 and I'm using arm compiler version 6.19 and I have also tried to compile your STM32F103_STM32_SK example, and I would get the compilation error like this

keil wrote:

Build started: Project: Start_STM32F103
*** Using Compiler 'V6.19', folder: 'C:\Keil_v5\ARM\ARMCLANG\Bin'
Build target 'Debug'
Setup/Retarget.c(345): error: conflicting types for '_sys_tmpnam'
int _sys_tmpnam(char * pBuffer, int FileNum, unsigned MaxLen) {
^
C:\Keil_v5\ARM\ARMCLANG\Bin\..\include\rt_sys.h(137): note: previous declaration is here
extern void _sys_tmpnam(char * /*name*/, int /*sig*/, unsigned /*maxlen*/);
^
1 error generated.
compiling Retarget.c...
".\Output\Debug\Start_STM32F103.axf" - 1 Error(s), 0 Warning(s).
Target not created.
Build Time Elapsed: 00:00:00

your STM32F103_STM3210E_Eval is using arm compiler version 5, which I do not have installed and I want to use v6 of the compiler.

SEGGER - Martin · Jan 9th 2024, 3:47pm

Hi again,

Also Please note that my keil version is 5.38 and I'm using arm compiler version 6.19 and I have also tried to compile your STM32F103_STM32_SK example, and I would get the compilation error like this

(...)

Setup/Retarget.c(345): error: conflicting types for '_sys_tmpnam'
int _sys_tmpnam(char * pBuffer, int FileNum, unsigned MaxLen) {

It seems Keil MDK has changed the signature of the _sys_tmpnam() function from
int _sys_tmpnam() in uVision v5.36 and earlier to
void _sys_tmpnam() in uVision v5.38.
Thanks for making us aware of this!

I have modified Retarget.c accordingly and attached it to this post.
Using that modified file, I was able to build our reference project for the STM3210-Eval board in uVison v5.38.
We will also include this modification in upcoming releases of embOS for Cortex-M and Keil MDK.

Regarding the initial problem:

.\Objects\marlin.axf: Error: L6915E: Library reports error: Conflicting stack/heap set up methods in use. __user_setup_stackheap, __user_initial_stackheap cannot be used with __initial_sp, __heap_base and __heap_limit

According to the documentation, this means the project is now using two different methods of heap/stack initialization when it must use one of those only:

developer.arm.com wrote:

Error: L6915E: Library reports error:Conflicting stack/heap set up methods in use. __user_setup_stackheap, __user_initial_stackheap cannot be used with __initial_sp, __heap_base and __heap_limit

You have most likely used __initial_sp, __heap_base, or __heap_limit to set up the stack and heap, but other independent stack and heap setup methods, __user_initial_stackheap or __user_setup_stackheap, are also in use. Use only one of the following stack and heap setup methods:

__initial_sp, __heap_base, __heap_limit.
__user_setup_stackheap.
__user_initial_stackheap. The legacy function. Arm recommends not using __user_initial_stackheap(), if possible.

Since embOS expects the symbols __initial_sp, __heap_base, __heap_limit in the start-up file, that method must be used with embOS.
Consequently, __user_setup_stackheap may not be used and must be removed from the start-up file.

I have modified startup_stm32f10x_hd.s accordingly and attached that as well.
Using that modified file, I was able to build your sample project in uVison v5.38.

Do the modified files solve the observed issues for you as well?
Please lt me know if I can be of any further help.

Best regards,
Martin

ali_asadzadeh · Jan 11th 2024, 11:00am

Dear Martin
Hi
Thanks for the update, Now it compiles, Please add the updates to the new release, also I wanted to test the embos on stm32F0 parts too, they needed stmcube code generation for new project to be setup, But if I add embos to the mix, it would generate errors, is there a video or document showing how to make new projects with keil using your embos, because it's a fantastic os and I dn ot know why I should use FreeRTOS or RTX, when I have the embos option.

Here is the error for the new error for the stm32f0 part projects

keil wrote:

RTE/RTOS/RTOSInit.c(22): error: 'SEGGER.I-CUBE-embOS_conf.h' file not found

you can get the generated project in this link
files.fm/u/qp2vejxtbs

SEGGER - Martin · Jan 11th 2024, 12:03pm

Hello Ali,

I'm not quite sure about your set-up in this particular case.

SEGGER.I-CUBE-embOS_conf.h should be generated by STM32CubeMX when creating a project that was configured for embOS.
However, it seems the *.ioc file included with your project files was not configured for embOS usage.

If so, you may simply cut the inclusion of SEGGER.I-CUBE-embOS_conf.h from RTOSInit.c.
Please be aware, however, that you will also need to disable the generation of the SysTick_Handler() and PendSV_Handler() in CubeMX and possibly apply further modifications as well.
Please refer to our Wiki for further information on how to integrate embOS into a CubeMX-generated project that was not configured for embOS usage.

By the way:
embOS for Cortex-M and Keil MDK includes a sample project for an STM32F0 as well (for the STM32F051R8-SK board), hence you might want to consider using that for your evaluation.
embOS for Cortex-M and Embedded Studio includes sample project for various STM32F0 devices and may therefore be an even better choice for evaluating embOS.

Best regards,
Martin

ali_asadzadeh · Jan 13th 2024, 2:25pm

Dear Martin
Hi,
Thanks for the update, I use keil to make new projects, not stm32cube, maybe the bug comes from there. Please try to make a new project using keil only, there is a checkmark with in the device the triggers stm32cube framework code generation, that I use that for initing peripherals, Please checkout this image

SEGGER - Martin · Jan 15th 2024, 9:34am

Hello Ali,

Okay, so you're including the STM32Cube HAL directly from within Keil MDK.
This combination is not something I have used before and since neither product is supported by SEGGER, I'm afraid I can be of limited help here only.

However, I'd assume that combination to work just as well after applying the modifications I had suggested above:

As the project is not generated in STM32CubeMX itself, SEGGER.I-CUBE-embOS_conf.h does not exist in your project and you will need to delete that include from RTOSInit.c.
You would need to perform some of the modifications mentioned in our Wiki, especially the modifications concerning the SysTick_Handler() and PendSV_Handler().
As you're not generating the project in CubeMX, you would need to apply some changes manually (i.e. delete the handler implementations and ensure valid interrupt priorities).

As mentioned before, for a straight-forward evaluation of embOS, you might also be interested in using embOS for Cortex-M and Keil MDK or, even better, embOS for Cortex-M and Embedded Studio instead.

Best regards,
Martin

Source Code

Source Code

C Source Code

C Source Code

Source Code

Share