- This topic has 26 replies, 3 voices, and was last updated 6 years ago by
.
-
Posts
-
Hi,
I’ve been following the mBed os importa instructions in https://visualgdb.com/tutorials/arm/import_sdk/
When building I’m getting this late in the process…
Severity Code Description Project File Line Suppression State
Error CreateProcess: No such file or directory mbed-os-example-blinky C:\Users\Phillip\Desktop\mbed\mbed-os-example-blinky\arm-eabi-g++.exe 1Just wondering where the path to the compiler is defined that’s causing the blowup?
Thanks – Phil.
Hi,
few days ago I had the same problem with imported project. This is reply from support:
“….We were able to reproduce the problem and narrow it down.
It looks like the amount of object files linked together in one executable triggers some internal bug in gcc that prevents it from launching the linker.It can be reproduced from command line by running arm-eabi-gcc -v @VisualGDB\Debug\my_project.link.rsp from the project directory.
Our best advice to work around it would be to split the project into the main binary + one or more static libraries (either by forking the MSBuild project, converting the forked version to a static library and moving the files between the project, or by creating a CMakeLists.txt file defining the main app and several libraries and importing it into VisualGDB).
We also have long-term plans for supporting special mbed project subsystem that will invoke the mbed building logic, so if time permits, you can simply wait until it is available.”
Because I can not do it, for now I moved my project to Eclipse + Platformio and will wait for “special mbed project subsystem” 🙂
Marek
Thank you Marek. Strange that it would be a gcc issue given that the project builds fine in mbed-cli on gcc on the same machine.
My VisualGDB subscription is up in a month, maybe now is the time to give PlatformIO a go.
Thanks again!
Hi,
We had actually done a detailed investigation on this issue could reproduce the problem by running gcc manually (and passing it a long list of .o files via an .rsp file). The difference comes from the fact that mbed first builds several static libraries (with less object files per library) and then links them together into the final ELF file. This results in less object files per command line than with VisualGDB, and hence doesn’t trigger the problem.
You can work around it by creating a similar project structure under VisualGDB – main executable + libraries.
We have also received increasing amount of feature requests for improving mbed support, so we might be able to support the advanced mbed project subsystem (similar to the advanced ESP-IDF project subsystem) in v5.4, although we won’t promise this 100% yet.
As for PlatformIO, it’s a higher-level framework that focuses on easy portability with a basic set of tools, while VisualGDB focuses on providing advanced debugging and code analysis/navigation functionality for larger projects that are not limited to any specific framework. Depending on your project requirements, either approach may work, but if you are planning to do non-trivial debugging or explore large 3rd-party code bases, you may find the features provided by VisualGDB worthwhile.
E.g. check out the new CodeJumps feature added to the upcoming Preview 8 (you can try out an experimental build with it here: http://sysprogs.com/files/tmp/VisualGDB-5.4.7.2499.msi) that can instantly visualize relations between different parts of your code:
Unfortunately, I never had to compile projects in this way.
Could you prepare some short instruction on how to divide mbed-os into libraries and link them with the main program? Maybe an example?
Marek
Support: thanks. I’ll have a go. I tried PlatformIO today .. easy setup, but the debugging was problematic. 3-4 seconds per step-over with ST-Link There’s something wrong with the way they’re driving the debugger. And bringing a project in is ultra-painful, it’s largely set up to start a project from scratch.
The problem is that our work as contractors means we hop from platform to platform all the time, that’s why I have VisualGDB, though most of us have VMs with each platform’s development tools on them. I’ve never had a lot of success with VisualGDB over the 4 or 5 years I’ve been paying a subscription for it, I always end up going back to the manufacturer’s platform, and having to learn it all over again each time we change projects.
Maybe it’s just asking too much for one product to cover all those diverse platforms. It’s such a nice dream, though… the mBed framework comes so close, if only it could debug.
Hi,
No problem.
@maras: The easiest way to split the project would be to copy the .vcxproj file, replace the project GUID in the copied one, add the second project to the solution, switch its type to static library (via VS Project Properties), reference it from the main project. Then make a copy of both .vcxproj files and do the actual splitting – remove roughly a half of the sources from the first project and remove the remaining sources from the second one. If the same problem reoccurs, please restore the backup copies and try a different split (e.g. only the file with main() in the main project and the rest of the source files in the other project). Let us know if you run into any issues with it and we will help.
@phildimond: Thanks for sharing your concerns. We will try to clarify this and help you find the best solution. VisualGDB itself doesn’t provide a “platform” – instead it provides a common set of development/debugging tools that work on many 3rd-party frameworks (e.g. STM32Cube, NXP McuXPresso, ESP-IDF, Arduino, mbed, …). Not sure what you meant by going back to the manufacturer’s platform – the VisualGDB projects are usually based on the manufacturer’s platforms.
VisualGDB can also be easily configured to build/debug projects with any other framework – simply import it as an external project and you will be able to use the debugger (immediately) and IntelliSense (after configuring include directories). You can use this approach to import a project built with either mbed-cli or PlatformIO and still develop/debug it with VisualGDB. The only difference compared to the upcoming advanced mbed subsystem is that you will have to tell VisualGDB the command line to build the project, configure IntelliSense directories and edit the configuration scripts manually when you need to make changes to your project (the advanced mbed subsystem will provide GUI for common configuration settings). This is fully covered by our tech support, so feel free to create another thread sharing any issues you encounter and we will walk you through getting it to work.
As for the PlatformIO IDE, it is built on top of the Electron platform (i.e. is essentially a Web App running inside a separate browser instance). This makes it truly cross-platform, however it also inherits all the drawbacks of browser-powered applications like slow performance and complications making large-scale GUI. VisualGDB is built on top of a different technology, so it features much more detailed code analysis logic, works much faster and provides convenient and detailed GUI for common scenarios, regardless of the underlying platform you choose.
Hope this explains. Let us know if you have any further questions and we will be happy to help.
@support: and what should I do with my_project-Debug.vgdbsettings and my_project-Release.vgdbsettings files ??
Hi,
If the project is msbuild-based, the static library project can be built without a .vgdbsettings file, hence you can simply keep the original files and not change anything.
My boss gave me the OK to spend a couplem of days to see if we could get somewhere with mBed / VisualGDB and I’m making some progress.
If I get a good outcome I’ll document it, but the trick seems to be to build a base project in the online compiler and export from there, not use the mbed-cli and import from that.
The compiler builds the mbed library as a static library, which will hopefully make importing to VisualGDB *way* easier. You can see the result of a basic blinky project with the latest mbed-os libraries (which are *so* much better than the older v2 ones in the VisualGDB project expert).
Hi,
No problem. Let us know if you encounter any issues and we will try to help.
Normally the importing process described in the tutorial should work, however it looks like it does trigger a gcc bug on particularly large projects.
I give up.
I spent the weekend trying this, then trying other examples, trying other imports. STM32 Cube MX blows up on the compile and libraries, mBed barely works and mBed-CLI doesn’t work at all.
I built a new Windows 10 VM and installed everything clean to make sure I didn’t have rubbish in the system,
I wonder if anyone has ever gotten anything beyond a Blinky working on VisualGDB? I’m buggered if I can. I think this was our last try with VisualGDB. I’m sure it’s *possible*, but I spent more time on this than building my last project in OpenSTM32 – *including* installing the tools and StM32 Cube!
Back to the multiple VMs, each with a vendor toolset. Sigh. Mikro C is the low end tool with the widest platform support, but it’s a bit painful to work with, but still *way* better than this. I had to tell the boss today that I give up.
Hi,
We have received feedback from other customers being able to develop large mbed projects with VisualGDB, although they mostly use our mbed BSP (repackaged version of mbed that passed our internal tests).
We are also happy to provide support for any issues you encounter along the way – simply let us know the exact errors you encounter and we will explain the underlying mechanisms and help you resolve them.
I tried develop anything with your mbed BSP, I created new project with ARM embed, device NUCLEO 429ZI, sample LED blink (RTOS), building this project and is OK.
Now I added netsocket Library and from now can’t build project without errors. When I resolve a lot of problems with missing includes, I got 26 errors like “SOMETHING was not declared in this scope” in mbed_retarget.cpp. Now I don’t have any problems with missing includes, so I don’t know where looking for.
I do not know how to work with your mbed BSP, I’m not a professionalist, I see that solving one problem does not lead me to success, but only to further problems.
Hi,
Just wanted to let you know that we have received more requests for better mbed support recently and were able to add a new advanced mbed project subsystem to VisualGDB.
Please try this build: http://sysprogs.com/files/tmp/VisualGDB-5.4.9.2553.msi (use the new mbed wizard).
We will post an official announcement for this tomorrow and a tutorial later this week.
- You must be logged in to reply to this topic.