Loading...
 

SW4STM32 and SW4Linux fully supports the STM32MP1 asymmetric multicore Cortex/A7+M4 MPUs

   With System Workbench for Linux, Embedded Linux on the STM32MP1 family of MPUs from ST was never as simple to build and maintain, even for newcomers in the Linux world. And, if you install System Workbench for Linux in System Workbench for STM32 you can seamlessly develop and debug asymmetric applications running partly on Linux, partly on the Cortex-M4.
You can get more information from the ac6-tools website and download (registration required) various documents highlighting:

System Workbench for STM32


Using Build Variables in debug Initialization Commands

Is there a way to use build variables like ${ProjDirPath}, ${ConfigName}, ${BuildArtifactFileName} in the debug initialization commands?

Now when I use them, I get error:
Reference to undefined variable ${var_name}

Hi,
I’m not so sure that I understand what you really want to achieve, so I may not have the right answer.
By my understanding, the build variables like ${ProjDirPath} etc. are provided by Eclipse and then passing to shell level command invoking. If your debugging is through OpenOCD, and the debug initialization commands means of commands within OpenOCD context, then the OpenOCD has no knowledge about build variables like ${ProjDirPath}.
There may some ways to replicate those macro definitions into OpenOCD in the shell level when invoking OpenOCD, but I’m not an expert in OpenOCD and I can’t tell.
If you describe more detail about what you want, it would be helping people to understand, and so better answer your question.

Yes, I want to pass build variables to OpenOCD via debug initialization commands.

Well, in fact I want OpenOCD to write my program in flash (STM32F407VE(G)T6) on debug start. So I’ve performed a search and found some instructions which advise using OpenOCD flash params in the debug initialization commands. They seem to work ok but require output file name. So I want to pass that name via build variables somehow.

But maybe there is an easier way?


I thought that all those functionalities be already available from the out of box software SW4ST32.
If you have biuld success, you should have an elf file available.
From the pane of C/C++ Projects, under your project, expend Banaries, there you should see the elf file generated for your project. Select it by click, then go pull down Menu of Run, chose Debug Configuration, chose Ac6 STM32 Debugging, and the elf file below it, find the Debub button at right low coner.
You should be all fine from there.

There may other way work also, by right click the elf file under C/C++ Projects, chose “Debug As” -> Ac6 STM32 C/C++ Apllication, this could be also working fine.

Yes, it works out of the box, but by default elf seems to be loaded is sram, not in flash. So when elf is big it has to be put in flash.

France

The problem is a bit more complex; the debugger always put the code where the link editor decides to put it, so changing where the code is placed (RAM or FLASH) has to be done by edititing the link editor script.

The default link editor script places code in FLASH, not in SRAM, so starting a debug session will flash your program on the board; I don’t know what makes you think the program was placed in RAM.

Note that there is also a “Target” submenu in the project context menu where you can clear or flash the target board with your program.

Bernard (Ac6)

1. It doesn’t perform flashing. I can’t see it in debug console. And when I put flashing commands manually in the initialization commands then I see it really happens.

2. What makes me think the program is placed in RAM is that I can compare the behaviour with IAR EWB. There’re 2 files (taken from ST libs): for placing code into flash and sram. So when I use sram vesion, the behaviour is the same as SW4STM32’s default. And when I use flash version, the behaviour is the same as SW4STM32’s with flashin commands.

P.S. Default .cfg file for OpenOCD generated by SW4STM32 while creating new board (STM32F404VET6) doesn’t work and needs to be edited (and as I can see it’s a well known problem)