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?
Sometimes I have a good idea how to extend one of my Processor Expert components with an extra feature, but then I step back because why implementing more than I need at the moment? Until another user of the component simply asks for the same thing, and here we go: if one or more can take advantage of a feature, that’s definitely a strong argument to add it :-). This happened with the RingBuffer Processor Expert component I’m using in many projects. And a reader of this blog asked to add some extra event methods: when an item is added or removed to the buffer.