Search Results

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…

> 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. W…

> 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 ar…

> 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…

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 se…

> 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…

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…

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 so…

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 su…

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: forum.segger.com/index.php/Att…214efb28b7a01bfcc941c8048 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.

> The purpose in my case is to create a set of information of the application and provide this to a bootloader and vice versa. This information block shall contain the start address, the end address and other information. That is the purpose in my case as well. The application is preceeded by a header containing this data, including an embedded checksum. This checksum is first checked by the bootloader during the update. The BL calculates and compares the checksum before executing an application…

The purpose of such an action is usually a runtime check across the whole application, comparing it with a precalculated checksum stored inside the image. I have done this for other MCUs (proprietary Fujitsu architectue), not Cortex M. So I can give only general advice. But the idea is to modify the linker map appropriately. Check the linker script file (*.ICF) for the highest section of interest for you. Split off a separate section with the same parameters as the preceeding one (or similiar) a…

Investigating a bit further, it becomes a bit more complicated. As I found out, the second zero-byte transfer is caused by the high-byte of the 16-bit access to SPI->DR. As somewhat veiled described in the reference manual, writes to the DR register go into a FIFO. Albeit a 4-byte FIFO makes limited sense for a 32-bit MCU. Checking example code for a similiar MCU (stm32F05x), 8-bit transfers are done via byte-write to the DR register. Implementing such a byte-wise access through a byte-pointer t…