Forum Replies Created
-
Posts
-
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.
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).
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.
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!
I have just been working on exactly that – building templates using the STM32F4Cube library and examples.
The process is fairly easy. First download and install the STM32F4Cube software.
1. Create a new directory for your solution.
2. Copy the template or example from the Cube library in there.
3. Create a new VisualGDB project in that same directory for the same processor you will be using.
4. Remove all of the source and header files from the VisualGDB project.
5. Copy in all of the source from the STM32F4 Cube project that you will need, plus the startup_stm32F4_whatever.s file from the MDK-Arm directory.
6. Right-Click on the VisualGDB project and select the VisualGDB Project Properties option.
7. Remove all the include file entries.
8. Add an include file entry for the project inc directory (the one you copied from the STM32F4Cube set).
9. Do a build – you will get errors for missing headers. Add the directories containing the required files into the includes per steps 6 & 7.
10. Add any source files associated with those headers to your Device Specific Source filter in your project (this will be for things like the HAL and CMSIS code, etc).
11. Iterate through 9 & 10 until you get all the required source and headers.By the end of those iterations you will have a project that builds and runs successfully. I just did exactly that this morning for the GPIO_EXTI example in the STM32F4 discovery example in the STM32F4Cube set, and wiull have a go at one of the Ethernet examples tonight (which will be the same, just a lot more libraries to add).
Why use these instead of the STM32 ones that come with VisualGDB? Because you get Ethernet and RTOS examples, plus I find the STM32Cube code to be better and operate at a higher level with the HAL implementation, basically.
Phil
Thank you – the timing was surprising. I logged in for the first time in a week just as you posted the reply!
I was just starting to play with getting an STM32F4 project built from scratch using the STM32F4Cube libraries when you made the post. That is an easier task but the tutorial helped as I foget the startup.s code – which explains why the build succeeded but resulted in no code!
I’ll give this a spin with the FRDM-K64F in a few days.
I wanted to congratulate you on a great product. There must be some reason that theis is not more widely known, but I have no idea why. Finally – one environment where I can do embedded MCU code, embedded Linux and Windows CE code, plus Windows code, all in Visual Studio and with TFS Online source control .. what a great product. And yes, I bought one license and will probably buy a couple more for our other developers once I get the build templates mainstream.
If you have those instructions, that would be great – even if there is just a manual somewhere. I can work out the arm gcc compiler flags myself fairly easily.
I agree that the Kinetis devices are less used than ST or NXP, but the K64 family might change things somewhat – a great combination of cost, package and functionality, and for the enthusiasts the FRDM-K64F board is great value for an Ethernet capable board.
We (our tiny company) are actually looking at moving new designs from LPC4088s to K64s for those reasons, which is why I’m asking.
Thanks!
Phil
