It seems nobody at Segger picked up the question yet ...
In the meantime, you could use a toolchain like this, and use it with the "standard" Embedded Studio.
Here a Segger Wiki explaining ho to do that :https://kb.segger.com/Use_an_externa…Embedded_Studio
Although the availability of CH32V boards is relatively low here, so I have no incentive to go that route myself at the moment.
I wonder why no Segger staff had picked up this thread yet ...
I'm using SES mostly for casual projects, and certainly not such old version.
But the linker error points to a function supposed to be in Segger's runtime library.
If you set up the project with the "wizard", the libraries are selected according the selected MCU variant, and certain other settings like semi-hosting or RTT support.
The wizard also selects matching device header and CMSIS version/paths, and startup code.
You didn't replace these components (headers, CMSIS, startup) with your own versions, did you ?
> ...in function `setlocale': ...
But I suppose this is the point of contention - setlocale() is a POSIX-conformant function, most probably introduced by your harfbuzz lib.
Very little of this POSIX compatible OS code exists on this MCU level (and in the Segger libs automatically included), sou you might need to review the requirements for using this library in your environment.
I never do that, to be honest.
Instead I rely on the IDE/toolchain to evaluate these dependencies when I create or change a project.
Dependency information is only required to create a make file.
I think this is a bad idea.
Because for one, this "shared" library code must be located in the BL application/sector, or else it would most probably delete itself partially when updating the application.
However, that defeats the main idea of a separate BL in the first place - you would need to update it almost everytime you update the application. Not to mention, it makes the build/link process much more complicated.
You are not the first one involved in a project that started out with much too optimistic resource requirement predictions.
Bite the bullet, and upgrade to the next larger MCU variant - or platform.
> However, if I try to download an ELF file to the target device using OpenOCD, it doesn't work and the target won't start.
I suspect an issue with the OpenOCD configuration or startup script.
To be honest, I have very little experience with OCD debuggers.
But in general, your BIN file and ELF file should be basically the same, created from the same compiler/linker output.
Comparing both files is almost impossible, but you could read out the Flash after programming, and comparing the contents.
Working a lot with STM32 parts, I mostly use the ST-Link debugger embedded on the board, re-flashed with JLink firmware.
That works fine for me.
> Is it possible to have a BIN file downloaded into flash as part of the debug process via gdb/OpenOCD, but then load the elf file subsequently via gdb?
I think this doesn't make much sense, the *.bin and *.ELF file basically contain the same information, and produce the same result (i.e. Flash content).
ELF files contain a lot of meta information reuired for debugging. Bin files do not.
> Also, where can I find what version of gdb is used when “GDB Server” is selected as the debugger?
> What arguments are sent to gdb and can these be inspected or changed?
Right-click on your project, select "Options", and select Debug/GDB server in the window that opens.
This should give you all the information you need.
(A screenshot upload did not work, so it has to work without ...)
I don't know if SES uses a pre-installed gdb or installs it's own version nonetheless.
Perhaps someone from the Segger staff can answer that.
To me, it looks like the former, i.e. using a preinstalled gdb.
Emitting "gdb --version" on the command line yields "GNU gdb (Ubuntu 9.2-0ubuntu1~20.04.1) 9.2".
And "which gdb" yields "/usr/bin/gdb".
> My colleagues need to pass the code to a fuzzing tool.
Assuming you talk about what I know as obfuscator tool, I don't know what want to achieve with that step.
Such a tool tries to hide certain details of the file from third parties, such as path names, libraries, variable and object names.
Commercial Dot-Net projects e.g. use to hide internals through an obfuscator, to impede reverse engineering.
There is no such thing present in HEX or S19 files.
All debug metadata have been stripped in the conversion process.
Nor do *.BIN files, at least those used to contain MCU firmware.
Those files consist of the raw values to program to each Flash cell, without any metadata (which means, not even addresses).
This implies *.BIN files must cover all addresses from the first to the last byte, and thus usually carry a large amount of superfluous data (0xFF) for all the gaps in the text / const data section.
ELF is basically the debug format, i.e. contains all the information for debugging (with the respective flags enabled).
Why not doing a post-build step, and convert the ELF output into an *.HEX or *.SREC file ?
These formats contain nothing but the actual code + const data.
Segger's objcopy tool (part of the binutils) could do that, for instance.
In the absence of more detailed information ...
How about just un-checking the "Show this dialog the next time" checkbox on the left side ?
Obviously, some user has or had installed something in this directory, or a directory with this name, and this file is gone now.
Did you copy the project from another location, i.e. another PC ?
I would check the "project explorer" window or the project options for this file, and probably remove it from there.
It is best to avoid absolute paths in project settings in general.
> Anyway, good to to know how it's done by the experts.
Let's settle on "professionals", as we (including myself) doing it for a living.
It can get much "worse" if you go into the automotive or aircraft industry.
In difference to the heavy machinery we build, an automobile or airplane is not in a safe state when you cut off all actuators.
> Maybe, the SEGGER IDE is not meant to be used in this way ...
As a side note, none of the target toolchains we use specifically designed for that, or include explicit support for this or other test tools.
The "support" comes with the test tool itself, which creates specific projects (derived from elaborate templates) for a certain platform.
Execution is usually done by running the IDE with the specific project as cmd line parameter, whenever possible headless.
As a side note, we do only module tests and most integration tests this way.
Validations (tests against user-visible requirments) are done manually of via a HIL.
> However, the platform.io ecosystem uses the github.com/ThrowTheSwitch/Unity testing framework that allows me to switch between a host and a target configuration.
This depends on your environment and context.
Because we deal with safety-related software, a "host configuration" is not an option.
The certification agency does not permit that as a valid environment, the target toolchain must necessarily be involved.
I am not sure if Googletest is the right framework for your puprose.
As the introduction says : "GoogleTest works on different OSes...", "Whether you work on Linux, Windows, or a Mac...".
These statements imply that host and target are identical.
And this is not the case for embedded development, especially the target the Segger toolchain supports.
Thus the test tool would need to integrate the target toolchain, deploy the test code to the target (which contains means to collect and transfer the test results to the host), and monitor the test procedure.
My company uses a commercial tool in the 5-digit price range (Win only, AFAIK no support for Segger integration).
And we use only simulated targets, which requires target toolchains that support such a target simulation.
I would use screc_cat (part of the SRecord tools) to join both HEX files into one in a post-build step.
Despite it's name, the tool can process many formats - including HEX.
J-Link driver installations in Windows come with a flashing tool, found under programs/Segger/J-Link<nnn>.
You can use this tool to flash any supported file to any supported MCU.
> ... which is a system file and should not be edited.
This is only relevant if you work with multiple toolchains and/or platforms in a project, and need to maintain source level compatibility.
For my private projects, I do whatever I like.
> I have added the include path of the gsl library to the preprocessor user include directories and have added the path to the actual libraries (gsl.a and gslcblas.a) to the linker_additional_files option.
This should be the proper way, at least it had worked for me.
Are you sure you have the proper library version (core, FPU ABI) ?
Perhaps there is some language conflict (C/C++, name mangling) ?
The GSL usually need a Unix/Linux- like platform, or the respective environment.
Perhaps there is something else missing.
Did you check the full compiler/linker output ?
I am assuming the special key characters (including backspace) are already consumed by Segger's (?) host driver for the debug pod.
In this case, there would hardly be any chance to get such characters to the debuggee via this route.
Perhaps the Segger staff on this forum can confirm this.
I suppose the missing "reent.h" file is part of FreeRTOS.
And thus you would need to include this manually in your SES project.
Reentrance would be a possible issue if you call newlib functions from different threads (including interrupts).
I am not sure if we mean the same.
Post-build steps happen after the build, not involving any build tools (compiler, linker).
This are usually external tools, or batches/scripts.
In the example I mentioned, this is a self-written tool that reads/parses the build artifact (an *.S19 file in this case), calculates a checksum over a given address range, and patches this checksum into the build artifact.
In other cases, these are output format converters (Bin, Hex, S19, ...).
In your case, I would suggest to have a look at the srec-tools (https://srecord.sourceforge.net).
It is a powerful tool to convert, split, join and manipulate FLASH/EEPROM file formats like Hex, S19 and many others.
The idea is to add the call the tool into the post-build step setup, or use a script (batch) for more complex tasks requiring multiple passes.
I would use a post-build command.
This can be found in Code->User Build Step in the project options.
Her a screenshot from a private project of mine:
Basically all modern toolchains have such an option.
My company uses it extensively to similiar purposes, like calculating a checksum over the Hex/S19 output and patch the checksum into the ex/S19 artifact.
I suppose you talk about a debug probe attached via USB.
You would need to look at the USB driver API (on the host PC side).
Perhaps it allows you to open a device with a SHARED property / flag.
We had a similiar issue in relation to CAN adapters and their USB drivers.
