Loading...
 

SW4STM32 and SW4Linux fully supports the STM32MP1 asymmetric multicore Cortex/A7+M4 MPUs

   With System Workbench for Linux, Embedded Linux on the STM32MP1 family of MPUs from ST was never as simple to build and maintain, even for newcomers in the Linux world.
And, if you install System Workbench for Linux in System Workbench for STM32 you can seamlessly develop and debug asymmetric applications running partly on Linux, partly on the Cortex-M4.
You can get more information from the ac6-tools website and download two short videos (registration required) highlighting:

System Workbench for STM32


sprintf / _sbrk make error

Hi,
I’m testing AC6 with STM32F4 Discovery. Enabled C99 on C prefs.


When using sprintf I got this from the linker:

‘Invoking: MCU GCC Linker’
arm-none-eabi-gcc -mcpu=cortex-m4 -mthumb -mfloat-abi=hard -mfpu=fpv4-sp-d16 -T”C:\STM32Toolchain\projects\Test_Hbridge_AC6\LinkerScript.ld” -Wl,-Map=output.map -Wl,--gc-sections -lm -o “Test_Hbridge_AC6.elf” @”objects.list”
c:/ac6/systemworkbench/plugins/fr.ac6.mcu.externaltools.arm-none.win32_1.3.0.201507241045/tools/compiler/bin/../lib/gcc/arm-none-eabi/4.9.3/../../../../arm-none-eabi/lib/armv7e-m/fpu\libc.a(lib_a-sbrkr.o): In function `_sbrk_r’:
sbrkr.c:(.text._sbrk_r+0xc): undefined reference to `_sbrk’
collect2.exe: error: ld returned 1 exit status
make: *** Test_Hbridge_AC6.elf Error 1

Where do I find the missing reference to _sbrk ?

thanks!

Tunisia

Hello,

This is a known error when you don’t add syscalls.c or specify -specs=nosys.specs in linker miscellaneous flags.
(For me I always prefer to add syscalls.c than nosys.specs)

If you have the STM32Cube_FW_F4 you can find syscalls.c within “.../Projects/STM32F4-Dicovery/Examples/BSP_SW4STM32”

Best Regards,
Tarek

Thanks, indeed I was missing syscalls.c
Now everything is ok.

Thanks! That worked for me as well.

Peter

Hi Tarek,
The semihosting was working in my application while the syscall.c file is exclude from build and in using the linker miscellaneous flags :
-specs=nosys.specs -specs=nano.specs -specs=rdimon.specs -lc -lrdimon
I tried the solution you proposed but it generates link errors.
Here are my steps :
- I removed the linker miscellaneous flags;
- I restore the syscall.c file (it was excluded from build);
Clean + Build but I get the following link errors :

../src/syscalls.c:63:27: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'asm'
register char * stack_ptr asm("sp");
 
../src/syscalls.c: In function '_sbrk':
../src/syscalls.c:116:18: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'asm'
  extern char end asm("end");
 
../src/syscalls.c:116:18: warning: implicit declaration of function 'asm' [-Wimplicit-function-declaration]
../src/syscalls.c:121:15: error: 'end' undeclared (first use in this function)
   heap_end = &end;
 
../src/syscalls.c:121:15: note: each undeclared identifier is reported only once for each function it appears in
../src/syscalls.c:124:24: error: 'stack_ptr' undeclared (first use in this function)
  if (heap_end + incr > stack_ptr)
 
make: *** [src/syscalls.o] Error 1


After several trials, I noticed that these errors were linked to the C99 standard.
All errors vanished when C Dialect option is empty unfortunately, the semihosting is not functional :
nothing is displayed in OpenOCD tab.

What is missing?
Thank you for helping


Hello,

Does anyone know why ST32CubeMX doesn’t copy syscalls.c to the application directory tree? Or at least provide a tick-box to either select or deselect it? Presumably everyone using the STM32 family is doing bare-metal programming, so syscalls.c or some other means is required for addressing sys calls.

Regards,

Peter

System call is the interface provided by OS.
As you mentioned, this is the programming on bare metal, which means no OS.
The syscall.c provided in this example is a reduced version of implementation, in hope to stub those “expensive” system functions and while provide a simple implementation to the other system functions, in this case for Standard Output.
As said, this example syscall.c is far away can be considered to meet wider requirements, so it shouldn’t to be included into CubeMX. It is only an example.

hello ,
i can’t run the example program found in SPN2 folder because an error occurs .
The error :
make all
Building file: ../user/syscalls.c
Invoking: MCU GCC Compiler
c:/ac6/systemworkbench/plugins/fr.ac6.mcu.externaltools.arm-none.win32_1.17.0.201812190825/tools/make/sh: syntax error: unexpected “(”
make: *** user/syscalls.o Error 2
user/subdir.mk:18: recipe for target ‘user/syscalls.o’ failed


I would (respectfully) disagree with bluenow and suggest that the bare-bones syscall.c be included in new Ac6 C/C++ projects. When I was starting out with SW4STM32, I ran into this problem too and eventually solved it on my own by looking at other complete project examples, eventually figuring out that this source file had to be part of my project. It was a bit frustrating though, and adds an extra hurdle for the “newbie” to get over.

The onus for removing or replacing syscalls.c with a more appropriate implementation for a more complex project, e.g. one that uses a RTOS or has more complex memory management requirements, should be on those people who, in all likelyhood, will be more advanced and experienced users and will know ahead of time that the default syscalls will need to be modified or replaced.


It might b nice to have it mentioned or discussed in the documents, though. Hunting for the solution for three days is a heck of a waste of time for me, and for countless other people, if the solution is a one-line entry in a suitable document.

I cannot understand why so many developers, when asked for an answer, say in essence “find out for yourself” when the newbie, like me, is trying to do just that.

Regards,
Peter


Dear ST support,

Using the nano.spec linker directive, compilation returns the error mentioned in the beginning of this post about _sbrk missing. This is seemingly due to the use of sprintf. Nevertheless, I am willing to use a sprintf function which requires no dynamic allocation (as we forbid this in a memory constraint application).

Is it possible to achieve this with the current provided glibc?
In addition, is it possible to have more information about the provided C library ?
Notably, could you provide the link to the repository holding the library source code (is it the classic glibc one found at https://www.gnu.org/software/libc/sources.html?)Question ?

Thanks for your help,
Best regards
Sylvain