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 two short videos (registration required) highlighting:

System Workbench for STM32


No symbol table?

Again, I created a ‘no-debug’ configuration, tested the resulting file. Then switched back to the Debug configuration and there is no symbol table.

I looked at the files with nm, the symbols are in the .o files, but not in the .elf

So the problem is with the linker.

I deleted the ‘no-debug’ configuration and did a clean/build. No help.

I will figure this out!

Last time it happened I abondoned the project, made a new one and copied the source files over.


make all 
'Building target: N476-x1.elf'
'Invoking: MCU GCC Linker'
arm-none-eabi-gcc -mcpu=cortex-m4 -mthumb -mfloat-abi=hard -mfpu=fpv4-sp-d16 -specs=nosys.specs -specs=nano.specs -T"../STM32L476RGTx_FLASH.ld" -Wl,-Map=output.map -Wl,--gc-sections -lm -o "N476-x1.elf" @"objects.list"  
c:/ac6/systemworkbench/plugins/fr.ac6.mcu.externaltools.arm-none.win32_1.7.0.201602121829/tools/compiler/bin/../lib/gcc/arm-none-eabi/5.2.1/../../../../arm-none-eabi/bin/ld.exe: warning: cannot find entry symbol Reset_Handler; defaulting to 08000000
'Finished building target: N476-x1.elf'
' '
make --no-print-directory post-build
'Generating binary and Printing size information:'
arm-none-eabi-objcopy -O binary "N476-x1.elf" "N476-x1.bin"
arm-none-eabi-size "N476-x1.elf"
   text	   data	    bss	    dec	    hex	filename
    192	     16	   1568	   1776	    6f0	N476-x1.elf
' '


-Matt

Ok, I found the problem. Kinda weird, I am an Eclipse user, not an Eclipse architech so I have no idea why this changed or how.

I had two projects, one that would build a symbol table, one that would not.

I found the .cproject files were different, in many ways.

I resolved the differences one by one until it started working.

The last difference, the one that got the symbol tables to build was:

.cproject file that would not build symbol table

<sourceEntries>
<entry flags=”VALUE_WORKSPACE_PATH|RESOLVED” kind=”sourcePath” name=”Src”/>
<entry flags=”VALUE_WORKSPACE_PATH|RESOLVED” kind=”sourcePath” name=”Inc”/>
</sourceEntries>


.cproject file that did build a symbol table

<sourceEntries>
<entry flags=”VALUE_WORKSPACE_PATH|RESOLVED” kind=”sourcePath” name=”“/>
</sourceEntries>


As soon as I copied over that line, poof - I had a symbol table.

It doesn’t make sense to me, I could think having the “Src” and “Inc” would make it have the symbol table (in fact I almost copied it the wrong way).

-Matt


France

Hi Matt,

Just a few question to try to better understand your problem.

How did you create the project (CubeMX or System Workbench)?

How did you create the Release (no-debug) build configuration (if you have to, that is if you created the project using CubeMX)?

How did you select the Release build? Did you activate the Release build configuration (project >> Build Configurations >> Set Active >> Release or Debug)?

Build configurations place their output in directory trees named after the configuration (Debug or Release); Could you check the debugging configuration (project >> Debug As >> Debug Configurations...) and verify it selects the right executable (Debug/program.elf or Release/program.elf)?

Could you compare the .project/.cproject files before and after doing the Release build?
I do not think the difference you note above was the real cause of the error, as neither the compiler nor the link editor should use these settings, but to investigate further we really need more information.

Thanks for your patience and help,

Bernard (Ac6)


>> How did you create the project (CubeMX or System Workbench)?

CubeMX

>> How did you create the Release (no-debug) build configuration (if you have to, that is if you created the project using CubeMX)?

Manage Configurations -> New... -> (enter name and description, copy from Debug) -> OK

Then Project -> Properties -> C/C++ Build -> Settings
Select Configuration: Release
-> Debugging to None
-> Optimization to Most
Apply
OK
(Just retested, at this point all is well)

Exit ac6, Run CUBE, make some changes

Restart ac6

Rebuild

Poof, Sybols are gone.

(So, obvious in the retest that it’s Cube thats the problem, not ac6)

>> How did you select the Release build? Did you activate the Release build configuration (project >> Build Configurations >> Set Active >> Release or Debug)?

Yes
In the retest I never selected the Release build.

>> Build configurations place their output in directory trees named after the configuration (Debug or Release); Could you check the debugging configuration (project >> Debug As >> Debug Configurations...) and verify it selects the right executable (Debug/program.elf or Release/program.elf)?

It selected the correct elf.

>> Could you compare the .project/.cproject files before and after doing the Release build?

The first time I did not have a saved project, instead I had another project (similar, same board) that was still working.

When I compared the .project files there were a match (names were different of course).

-Matt

France

Hi Matt,

OK, now I understand better; the problem is obviously coming from the re-gereration of the project by CubeMX.
Which version of CubeMX are you using, and which generation options have you selected?
With earlier versions of CubeMX (and possibly also the last one...) if you modified the project under Eclipse, CubeMX get lost and confuse things... In this case, the best bet is to save the .project and .cproject files before regenerating with CubeMX, then restore the saved ones before restarting System Workbench...

Anyway, if you don’t select new third-party components (like FreeRTOS) CubeMX should not modify the project, only modify source files. This is especially true with the last version of CubeMX if you generate the project in the root directory.

Sorry for the inconvenience,

Bernard (Ac6)

France

Hi Matt,

It seems that is a known problem with CubeMX that is still present in v4.14 but should be solved by the upcoming v4.15. In fact the problem is that some source files are not compiled due to project file corruption, so the debugger is not able to correctly debug the program.

In the mean time, the only workaround I see is saving and restoring the .project and .cproject files when regenerating the source code from CubeMX; not so convenient but the new release should come out soon.

Bernard (Ac6)