Search Results

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

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.

> Completely understandable. We will add native support to our wishlist but no promises. > You could try openOCD/pyOCD. Both support a big variety of different debug probes and can be used in Embedded Studio via the universal GDB interface. > It might not have all debug features then but the basics should be there. To be honest, I didn't even try that route (GDB-Server) yet. If I understood this correct you mean the Segger GDB server which supports openOCD/pyOCD debuggers. And one of the named d…

Thanks for the quick response. And to respond in reverse order ... > You can change the default new project folder under: Tools->Options->New Project Directory This is exactly what I needed. I overlooked this property until now - but to my defense, the number of setting items is a bit overwhelming ... For the standalone ST-Link, it sounds as I can write it off now. I'm using mostly Linux, and I suppose you mean a GDB server from ST, which needs to match the host OS. While ST's Cube IDE somewhat …

I understood that SES basically supports only the J-Link debugger, which is ok for. Though I have some questions related to J-Link conversion firmware for other debug pods. The ICDI (from TI, e.g. used on their Launchpad boards) is not and probably will not be supported, right ? There is such a conversion J-Link firmware for the LPC-Link2. I suppose it does not support the older version, called "LPC-Link". And thirdly, I successfully converted several ST-Links on STM32 discovery boards to J-Link…

Ok, thank you for the clarification.

I'd like to add some information, but the original thread is closed now ([Solved] Bug report: STM32F3xx CPU support package has incorrect memory map). Checking the current package status, this package installed is at version 2.04, and no update available. forum.segger.com/index.php/Att…634e685072333365dc4de4d9b hought RAM size defined in the memory map XML for the mentioned model (F303VCTx) coming with this package is wrong, 0x0C000 instead of 0x0A000.

> Unfortunately the RAM size for some of the subfamilies was set incorrectly, meaning larger than actually available on the device. > Because of this memory addresses were used which are not actually available on the device. > As the stack is usually placed at the end of the RAM region, it hard-faults on the first push instruction. Ah, ok. Now I see it. For my device, the memory map file says: <root name="STM32F303VCTx"> <MemorySegment name="FLASH1" start="0x08000000" size="0x00040000" access="R…

There seem to be more issues with the STM32F3xx support package. First I tried to create an application for the F3 discovery (F303VCT6), using the provided startup and vector files, and replacing everything else with ported SPL code. This application ended up in a hardfault in between the first 5 instructions of SystemInit (the first function called after the reset vector). More precisely an IMPRECISERR, with STKERR set (bus fault on stacking for exception entry). The stack address, including th…

I would still check the documentation/tutorials for Ozone, it needs to derive information about Flash sector locations and sizes of the target MCU from somewhere. And the flashing modus, depending on the ELF contents. I use the debugger integrated in ES, assuming it is the same "core" as Ozone. Only here it is (supposedly) fed from the ES project settings. By the way, I also had a strange problem recently, were I just did not get the SysTick interrupt to run. It turned out the vector file and li…

Which sounds more like a problem with the debugger settings. Perhaps your project contains a "mass erase" setting for the flashing process, or a script the toolchain/debugger uses. By the way, are you sure the bootloader and the application are not located in the same sector ?

Quote from nibbly78: “Eclipse does not know about the bootloader either... Eclipse is settup to only call "make clean" and "make app_debug" (so no access to compiler/linker etc to my knowledge) ” This is not related. "Make clean" only affects the sources and the build, not the target. And "make_app_debug" makes the target application using the "Debug" project settings - whatever they are. As a side note, one can easily make the "Debug" and "Release" project settings identical ... To your bootloa…

Not that I have tried it directly, but Ozone is a standalone debugger for such purposes. AFAIK it is free to use for non-commercial purposes, like SES.