Unlike CodeWarrior, the Kinetis Design Studio (at least in V1.1.1) does not offer a choice between C and C++ projects. That makes sense with the GNU ARM Eclipse plugins, other than the CodeWarrior gcc integration, there is no need for setting up a special tool chain for C++ (see “Compiling C Files with GNU ARM G++“). While this is great, things are not perfect yet, so I’m providing in this post the information needed to properly setup a C++ project with Kinetis Design Studio V1.1.1.
Sometimes I think that a problem should be solvable in a few minutes, and then it turns out that it lingers around for months. Very, very frustrating! Such a thing is getting the USB 4.1.1 stack running on the FRDM-K64F board. I have that board since April 2014, and it took me 7 months to get the FSL USB stack running on it :-(.
When I started the McuOnEclipse project back in 2012, I did not expect that it would create that much of attention :-). So far I’m sharing the project files on GitHub (see “McuOnEclipse goes Git“). GitHub is excellent for sharing sources, but not a good way to share release (binary) files. It is somewhat ok for small/few files, and initially that worked well for the few Processor Expert files (see “Processor Expert Component *.PEupd Files on GitHub“). However, with the amount of components and binary releases, the GitHub repository gets bloated. So I’m performing some maintenance work, and so I’m moving binary releases to a new McuOnEclipse SourceForge site.
Sometimes, there are ugly bugs in tools, and without knowing about them, it is likely to spend hours and hours, and of course to be frustrated. Knowing about these issues does not remove the issue, but at least helps to cut time to deal with it. And here is one which was nagging on me for a while with the GNU GDB debugger in Eclipse…..
I was happily debugging my project, making some changes, and suddenly I cannot debug it any more. What happens is that I can download the binary with GDB, but it immediately terminates and disconnects:
After digging and doing some trial and errors, I have found what is causing this.
When using a bootloader (see “Serial Bootloader for the Freedom Board with Processor Expert“), then I usually protect the bootloader FLASH areas, so it does not get accidentally erased by the application ;-). When programming my boards with the P&E Multilink, then the P&E firmware will automatically unlock and erase the chip. That’s not the same if working with the Segger J-Link, as it but requires extra steps.
Student: “Professor, my application does not work!”
Professor: “What is the problem?”
Student: “I don’t know, but the LED on my board is not blinking.”
Professor: “Can you step through the port initialization sequence and check if the clocks are initialized correctly?”
Student: “I have pressed the ‘Run’ button, I’m not debugging”.
Professor: “Why are you not debugging?”
Student: “I always do a ‘Run’, and I do ‘Debug’ only if needed.”
Clearly, I’m not immune to the ‘déformation professionelle‘. I very rarely use ‘Run’, because it simply does not offer much value compared to ‘Debug’ during development. If using ‘Run’ and then there is a problem, I have to ‘Debug’ anyway, why not ‘Debug’ from the beginning? It is simply not an efficient way to work for me. Or I’m missing something?
At FTF 2014, Freescale made the announcement that CodeWarrior won’t support all the new ARM Kinetis devices coming out in the future: they will be supported with the free-of-charge Kinetis Design Studio (KDS) instead. As for myself, this is a big shift from a well established CodeWarrior toolchain to something new. A question which came up recently several times in the forums and in other posts is: how do CodeWarrior and KDS compare with each other?