Search Results

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

Not sure if this is the right place, because responsibilities seem somewhat mixed. Anyway, I a m having trouble creating proper output of the SPI peripheral on a stm32C031C6 - the one on the ST Nucleo C031 (MB1717B). I am configuring the SPI for 8-bit transfers, and debugging shows the corresponding config register (CR2) is set correctly. However, watching the SPI signals, I can see two two 8-bit transfers generated by each write to SPI->DR. The first value is a correct byte I intend to transfer…

The problems seems to be gone now. What I have done was the usual update routine on a Ubuntu/Mint PC (apt-get update, apt-get upgrade, apt-get dist-upgrade). I can see all avaiable packages now, and install them from the manager. Most probably was really a problem with distribution, it seems to still have a few rough edges.

As far as I understand it, Rowley/Crossworks only shares the GUI and some tool interfaces with SES (like the package manager GUI). The actual toolchain (compiler, assember, linker) are different, and package format (and thus packages) are different. As a consequence, the startup files and libraries ("standard C libs") are different. I do quite a few projects for STM32 MCUs, mostly based upon the "old" standard peripheral library which is not supported by ST (and SES) anymore. Copying in the old …

I didn't try an "external built" project yet, but I don't quite understand the purpose. If you build it with a make file inside your IDE and want to debug it afterwards in the IDE, you could do a normal "C/C++" project. I view it as an option for projects built with other toolchains, or self-build libraries. Anyway, one option would be to try Ozone as debugger. And second, I would try to set the "Debug->Debugger->Command Arguments" in the project options to the proper executable file name. forum…

I recently reanimated an older laptop, installing Linux Mint Mate 21.1 (the 64-bit version). One of the first applications I installed was the latest SES version (V7.12a), which went smoothly as well. Only the package manager fails to download any package lists, complaining about "Request aborted". All the internet/proxy settings seem ok, I downloaded the packages on the same PC and installed them manually (using the respective menu option). forum.segger.com/index.php/Att…8589264028e2aff19359791…

As Nino posted, sleep modes and wake-up are a known source of trouble for debugging. Though this seems not to apply in your case. Quote from Eqqman: “Everything craps out at the function prologue assembly for HAL_UART_Transmit() : ldr r0, =0x200007D8 <huart2>. ” I am not too well versed in assembler code, but this code is supposed to load a 32-bit word into a core register. I can't really imagine how it could fail. Or does it happen in following instructions ? Leaving aside the quality of the HA…

Now this was a pure assumption on my side. My next step would be to step into the "offending" code on instruction level, and watch relevant port and RCC registers. The latter one's are where the power to the individual peripherals are enabled. In my case, I had accidentally written a GPIO config to port A instead B, overwriting the SWD pin config. Quote from Eqqman: “The debugger pins for the L062 are PA13/14 while UART2 is PA2/3 and UART1 is PA9/10. None of my code touches the debugger pins but…

Reading up on openOCD and GDB, I (hopefully) understand that point a bit better. Up to now, I usually preferred native support within the IDE/Debugger, or readily configured GDB server setups (like the one's Eclipse-based IDEs come with). And checking my revived old hardware, the results were not exactly encouraging. The standalone ST-Link is V.1, i.e. the broken USB driver implementation by ST. While I managed to find a LPC-Link2 and successfully converted it, the JLink "disappears" as soon as …

Check your exact target MCU, and the datasheet. I had a similiar effect when I accidentally tried to reconfigure the SWD pins of the target. The debugger/JLink "screwed up" immediately.