How to create a *.axf-File with Visual GDB

[runout]

Hi,

what is the clean Path to generate a *.axf-File with Visual-Studio + Visual-GDB

I’ve found a file …\VisualGDB\Debug\EmBGM13P22F512GA_Test01.mkbin.rsp
Is that the right place?
Or is it supported by the project-properties-Settings?

Kind Regards

 

[support]

Hi,

The .axf extension is used by the Keil compiler for the ELF files. VisualGDB follows the Linux naming convention for the built files, hence the ELF files it produces have no extension. I.e. you can find an equivalent of the AXF file for your project under the following path:<Project Directory>\VisualGDB\Debug\EmBGM13P22F512GA_Test01.

The .rsp files are used to pass the command lines of the tools, avoiding the Windows command line length limitation of 8192 characters. They do not contain any code or symbols on their own.

[runout]

Hi does it mean, a ELF-File is exactly the same as a AXF-File?

that (gcc)-linker options generate a “real” axf-File: (by Silabs Simplicity-Studio)
-g -gdwarf-2 -mcpu=cortex-m4 -mthumb -T “${workspace_loc:/${ProjName}/efr32bg13p632f512gm48.ld}” -Xlinker –gc-sections -Xlinker -Map=”${BuildArtifactFileBaseName}.map” -mfpu=fpv4-sp-d16 -mfloat-abi=softfp –specs=nano.specs

that (gcc)-linker options generate a elf-File: (w/o extension) in Visual GDB
-o “C:\xxx\EmBGM13P22F512GA_Test01\VisualGDB\Debug\EmBGM13P22F512GA_Test01″ -Wl,-gc-sections -L”Stack/platform/radio/rail_lib/autogen/librail_release” -L”Stack/protocol/bluetooth/lib/EFR32BG13P/GCC” -l”rail_efr32xg13_gcc_release” -l”bluetooth” -l”mbedtls” -l”psstore”

btw:
in VisualStudio/VGDB it’s very simple to extend the elf-file Name.
In “Properties” (Alt+Enter) /General/Target Extension (normally empty) set to “.axf”

BUT, this is not the Solution to the Issue descripted above.
Is it related to Parameter “-g -gdwarf-2” ??

I need “real” axf-Files as input for the Silabs Converting-Tool
to generate gbl-Files.

Kind Regards

 

[support]

Hi,

Although we have not specifically checked the inner workings of Simplicity Studio, the AXF extension does typically correspond to the regular ELF files.

Indeed, you can override the file extension via VS Project Properties, although due to the internal VS limitations the default extension needs to be the same for all project types, hence we picked the Linux-style empty extension as the default.

The “-g” option should normally not affect the linking and is only used during compilation, hence VisualGDB does not pass it to the linker. You can override this behavior via VS Project Properties -> Linker -> Command Line.

That said, the VisualGDB-level command line you mentioned is missing a linker script (the .ld file) that should be normally picked automatically once you select a device in the VisualGDB wizard. If this is a manually created stand-alone project, please ensure you have a linker script specified on the first page of VisualGDB Project Properties (and also ensure you have the -mcpu, -mfpu and -mfloat-abi passed to the linker as well, as those options affect the type of the pre-built standard C library used to link the executable).

[runout]

Hi,

thank for your reply.
The problem is meanwhile solved.

The differences of the Linker-Scripts and the startup_xxx.c are significant.
There are no differences of system_xxx.c between Simplicity-Studio and VGDB.

In the Simplicity-Linker-Scripts are sections like text_apploader, text_application.
This is neccesary for converting ELF/AXF-File via objcopy and Commander.exe (from Silabs) to *.gbl-files

I use “fixed heap & Stack”-Option.
_sbrk() was defined double:  in StackAndHeap.c  (VGDB) and retargetio.c (Simplicity-Studio)

Anyway, it is possible to switch from Simplicity-Studio/Eclipse 🙁 to VGDB :-).

last question:
How to avoid this Message? “The memory location used for the Stack is not writable… You can disable automatic stack checking via…”
Have no found any Option.
maybe: Preprocessor-Macros: “__StackLimit=0x20000000” ???

Kind Regards

 

 

 

 

 

 

• This reply was modified 4 years, 6 months ago by runout.

Attachments:

You must be logged in to view attached files.

[support]

Hi,

Indeed, the VisualGDB’s startup file looks different from the original one. Our BSP generation logic parses the interrupt vector list from the original file and generates a compatible startup file that has the same interrupt vector definitions, but is also compatible with VisualGDB-specific parameters (e.g. FLASH/RAM memory layout).

The linker script is also regenerated based on the memory map. This enables GUI-driven features like “fixed-size stack/heap”, however would indeed break 3rd-party tools that expect specific sections in the ELF image. Using the original ELF file instead should fully solve the problem.

The stack error is shown because the original linker script places the __StackLimit symbol at the beginning of RAM, while most SDKs from other vendors place it to the end of RAM:

  __StackTop = ORIGIN(RAM) + SIZEOF(.stack_dummy);
  __StackLimit = ORIGIN(RAM);

The easiest way to work around this would be to locate the EndOfStackSymbol element in the .vgdbsettings file and manually change its contents to __StackTop to match the name used in the EFM32 linker script.

[Author]

Posts