Sysprogs forums › Forums › VisualGDB › MbedOS Project – Can't change compiler
- This topic has 4 replies, 2 voices, and was last updated 5 years, 9 months ago by support.
-
AuthorPosts
-
January 16, 2019 at 16:49 #23489ChrisParticipant
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)January 16, 2019 at 16:59 #23492ChrisParticipantSrry for the doublepost. For some reason I couldn’t modify my first post.
Attachments:
You must be logged in to view attached files.January 18, 2019 at 04:39 #23524supportKeymasterHi,
Thanks for reporting this. We have fixed it in the following build: http://sysprogs.com/files/tmp/VisualGDB-5.4.100.2751.msi
January 21, 2019 at 16:09 #23547ChrisParticipantHello,
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.txtThe 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) bytesImage: Build/NUCLEO_F746ZG/Debug\###.bin
========== Build: 1 succeeded, 0 failed, 0 up-to-date, 0 skipped ==========Is this intended behaviour?
January 21, 2019 at 21:52 #23549supportKeymasterYes, 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.
-
AuthorPosts
- You must be logged in to reply to this topic.