How to get SWO working with STM32CubeMX-generated Makefile?

[pgregson1]

Posted on November 10, 2017 at 13:29

Hello,

I am using the arm-eabi-none- toolchain on Mac OS X 10.11 using STM32CubeMX 4.22.1 to create the initialization code, a Makefile that I wrote and the ST-Link/v2 for programming.  With that environment, I can get SWO printf debugging working without problems.  However, when I use the same software together with the Makefile created by STM32CubeMX (with 'Makefile' selected in the 'Toolchain / IDE' box), SWO pintf debugging does not work.  Sadly, I have to switch from my hand-crafted Makefile to the one generated by STM32CubeMX and so I must get this working.

Can anyone help with this?  I can post a minimum example if necessary, but I suspect that there is a flag missing somewhere.  Since my Makefile searches the Drivers subdirectory for all files that meet the search criteria, but the STM32CubeMX Makefile doesn't appear to do that, I think that mine is including a file that the Cube one doesn't.

Could someone advise me?

Thanks, and

Best regards.

Peter

[Doug Kehn]

Posted on November 10, 2017 at 14:12

I suggest capturing the output from each 'make' and then start comparing the output. Look for differences in compiler/linker flags and for files compiled by your makefile versus CubeMX makefile.

Regards,

...doug

[pgregson1 · Accepted solution]

Posted on November 12, 2017 at 04:40

I found the problem.  I needed to have syscalls.c included as one of the sources.  Since STM32CubeMX includes the sources explicitly, it wasn't included in that list.  By contrast, my makefile searches the source directory and includes all of the sources there automatically.

I hand-edited the STM32CubeMX-generated Makefile to include syscalls.c to do this automatically, and then SWO printf worked fine.  

I must thank Doug Kehn for his helpful suggestion on how to find the problem.

Is there a way to get STM32CubeMX to include syscalls.c and perhaps other files in the list of sources?

Best regards,

Peter

[Doug Kehn]

Posted on November 13, 2017 at 14:29

What I do is add

-include $(TARGET).mak

to the CubeMX generated Makefile right before the '#build the application' comment. In $(TARGET).mak, I add

C_SOURCES += \

$(filter-out $(C_SOURCES_EXCLUDE),$(wildcard <path>/*.c))

C_SOURCES_EXCLUDE =

...plus other 'stuff' to enhance/modify the build. C_SOURCES_EXCLUDE comes in handy when there are one or more source files in <path> that are not to be compiled.

Maybe this construct for C_SOURCES/C_SOURCES_EXCLUDE could be incorporated into the CubeMX generated Makefile?

Regards,

...doug

[pgregson1]

Posted on November 13, 2017 at 14:46

Hello,

That is basically what I do in my hand-crafted makefile.  I use a recursive wild-card search to search the other directories for C sources the same way, and do the same to find startup_stm32f103xb.s the load script, the necessary include files, etc.  I can do this because I have a policy of having a directory tree for every project, which I can enforce with a script to create the tree.  However, I am less good at making sure that all the bits go in the right places.  Also, this way I can create libraries for each project with the files in one or more lib directories (lob-lcd, lib-accel, lib-GUI, etc.) and it is much easier to build projects that I find on the internet.

I like your inclusion of C_SOURCES_EXCLUDE.  That is something that I will incorporate, probably for directories as well as files.

Why can't CubeMX do this?  It's easy and helpful.

Best regards,

Peter