MbedOS Project – Can't change compiler

[Chris]

Hello,

initialy I tried to prepare a project, designated to use the ARMCLANG compiler.
Aber clicking “Build” I noticed, the IDE tried to launch the regular python script in combination with ARM_GCC, which I didn’t configure.
Although, in the end, the IDE passes the correct path to ARMCLANG.

—— Build started: Project: demo_###, Configuration: Debug NUCLEO_F746ZG ——
VisualGDB: Run “C:\Python27\python.exe D:\###\mbed-os_v51100\tools\make.py -t GCC_ARM -m NUCLEO_F746ZG –profile D:/###/mbed-os_v51100/tools/profiles/debug.json –source . –source D:\###\mbed-os_v51100 –build Build/NUCLEO_F746ZG/Debug” in directory “D:\###\demo_###\demo_###” on local computer
usage: make.py [-h] [-m MCU] [-t TOOLCHAIN] [–color] [–cflags CFLAGS]
[–asmflags ASMFLAGS] [–ldflags LDFLAGS] [-c]
[–profile PROFILE] [–app-config APP_CONFIG]
[-p PROGRAM | -n PROGRAM | -L | -S [{matrix,toolchains,targets}]]
[-j JOBS] [-v] [–silent] [-D MACROS] [-f GENERAL_FILTER_REGEX]
[–stats-depth STATS_DEPTH] [–automated] [–host HOST_TEST]
[–extra EXTRA] [–peripherals PERIPHERALS]
[–dep DEPENDENCIES] [–source SOURCE_DIR]
[–duration DURATION] [–build BUILD_DIR] [-N ARTIFACT_NAME]
[–ignore IGNORE] [-b BAUD] [–rpc] [–usb] [–dsp] [–testlib]
[–build-data BUILD_DATA] [-l LINKER_SCRIPT]
make.py: error: Could not find executable for GCC_ARM.
Currently set search path: D:\Programme\Keil_v5\ARM\ARMCLANG\bin
————————————————————-
Command exited with code 2
Executable: C:\Python27\python.exe
Arguments: D:\###\mbed-os_v51100\tools\make.py -t GCC_ARM -m NUCLEO_F746ZG –profile D:/###/mbed-os_v51100/tools/profiles/debug.json –source . –source D:\###\mbed-os_v51100 –build Build/NUCLEO_F746ZG/Debug
Directory: D:\###\demo_###\demo_###
VisualGDB: Error: Command-line action failed
========== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped ==========

I then tried to change the compiler to ARM_GCC just to test what would happen.
There I noticed, regardless of what it configured in “VisualGDB Project Properties”, I neither could press Apply (greyed out), nor could I actually change the setting.
It would always revert to ARMCLANG after checking in on “VisualGDB Project Properties” again.

 

Is this probably a missonfiguration on my part or actually a bug?

PS.: I’m using a local shared mbed-os directory.

PPS.: By the way, I noticed that some mbed_config.h entries, aren’t correctly displayed / imported.
For example (using mbed-os v5.11) mbed-mesh-api.thread-master-key is supposed to be an array of Bytes in hex.
But it is only shown as “{0x10,”. (See attachment)

• This topic was modified 5 years, 10 months ago by Chris.
• This topic was modified 5 years, 10 months ago by Chris.

[Chris]

Srry for the doublepost. For some reason I couldn’t modify my first post.

Attachments:

You must be logged in to view attached files.

[support]

Hi,

Thanks  for reporting this. We have fixed it in the following build: http://sysprogs.com/files/tmp/VisualGDB-5.4.100.2751.msi

[Chris]

Hello,

 

today I tried v5.4R2 of VisualGDB.
Now VisaulGDB does accept the changes made to the compiler. At least within the ProjectProperties.
But regardless, the system seems to switch back to use GCC_ARM compiler in the background.

Although I configured a new project, refering to an already checked out mbed-os, utilizing ARMCC compiler, during the project initialization I receive the following output:

Checking if any source files need uploading…
[Warning] D:\###\MbedProject1::: Compiler version mismatch: Could not detect version; expected version >= 6.0.0 and < 7.0.0
Building project MbedProject1 (NUCLEO_F746ZG, GCC_ARM)
Scan: MbedProject1
Scan: mbed-os_v51100
Compile [ 0.1%]: main.cpp
System.OperationCanceledException: The operation was canceled.
at n51.l(String a)
at n51.c_2()
at zz.m()
Checking if any source files need uploading…
[Warning] D:\###::: Compiler version mismatch: Could not detect version; expected version >= 6.0.0 and < 7.0.0
Building project ### (NUCLEO_F746ZG, GCC_ARM)
Scan: demo_BACnet4Mbed_vs
Scan: mbed-os_v51100
Compile [ 0.1%]: main.cpp
Saved the code model to D:\###\VisualGDBCache\###-Debug-NUCLEO_F746ZG\BuildCommandLines.txt

The actual build of the project then again seems to be handled via ARMCC toolchain, acording to output:

—— Build started: Project: demo_BACnet4Mbed_vs, Configuration: Debug NUCLEO_F746ZG ——
VisualGDB: Run “C:\Python27\python.exe D:\mbed-os_v51100\tools\make.py -t ARM -m NUCLEO_F746ZG –profile D:/mbed-os_v51100/tools/profiles/debug.json –source . –source D:\mbed-os_v51100 –build Build/NUCLEO_F746ZG/Debug” in directory “D:\demo_BACnet4Mbed_vs” on local computer
Building project demo_BACnet4Mbed_vs (NUCLEO_F746ZG, ARM)
Scan: demo_BACnet4Mbed_vs
Scan: mbed-os_v51100
Compile [ 0.1%]: mbed_tz_context.c
[…]
Compile [100.0%]: us_ticker.c
Link: ###
Elf2Bin: ###
| Module | .text | .data | .bss |
|—————————|—————|————-|—————|
| [lib]\c_w.l | 11207(+11207) | 16(+16) | 348(+348) |
| [lib]\cpprt_w.l | 76(+76) | 0(+0) | 0(+0) |
| [lib]\fz_wm.l | 18(+18) | 0(+0) | 0(+0) |
| [lib]\m_wm.l | 48(+48) | 0(+0) | 0(+0) |
| anon$$obj.o | 32(+32) | 0(+0) | 256(+256) |
| main.o | 120(+120) | 0(+0) | 28(+28) |
| mbed-os_v51100\cmsis | 1093(+1093) | 0(+0) | 0(+0) |
| mbed-os_v51100\components | 199(+199) | 0(+0) | 0(+0) |
| mbed-os_v51100\drivers | 1114(+1114) | 0(+0) | 152(+152) |
| mbed-os_v51100\features | 1150(+1150) | 12(+12) | 12868(+12868) |
| mbed-os_v51100\hal | 4712(+4712) | 39(+39) | 240(+240) |
| mbed-os_v51100\platform | 5248(+5248) | 108(+108) | 561(+561) |
| mbed-os_v51100\rtos | 13029(+13029) | 2554(+2554) | 4560(+4560) |
| mbed-os_v51100\targets | 16106(+16106) | 32(+32) | 1108(+1108) |
| Subtotals | 54152(+54152) | 2761(+2761) | 20121(+20121) |
Total Static RAM memory (data + bss): 22882(+22882) bytes
Total Flash memory (text + data): 56913(+56913) bytes

Image: Build/NUCLEO_F746ZG/Debug\###.bin
========== Build: 1 succeeded, 0 failed, 0 up-to-date, 0 skipped ==========

 

Is this intended behaviour?

[support]

Yes, even when using the Keil compiler, VisualGDB will internally use the GCC mode to query the project structure (VisualGDB reconstructs it from analyzing the GCC command lines). This should not affect the build, or cause any side effects.

Regarding the toolchain change, please try our latest internal build: http://sysprogs.com/files/tmp/VisualGDB-5.4.100.2756.msi

If the toolchain change is still ignored, please check if the “Apply” button becomes active when you change the toolchain. If not, please consider sharing a screenshot of your project properties and we will try to reproduce it on our side and release a hotfix.

[Author]

Posts