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.
Protected FLASH Pages with Processor Expert
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.”
Professor: “Ahhhhhhrrrrgggg!”
Run and Debug in Eclipse
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?
CW vs KDS
In “Semihosting with Kinetis Design Studio” I used printf() to exchange text and data between the target board and the host using the debug connection. Kinetis Design Studio (KDS) has that semihosting baked into its libraries. What about if using the GNU ARM Embedded (launchpad) tools and libraries (see “Switching ARM GNU Tool Chain and Libraries in Kinetis Design Studio“)? Actually it requires two more steps, but is very easy too.
Semihosting Output
P&E has just released a new version of their Eclipse plugins for the set of GNU ARM Eclipse debug plugins. The GNU ARM Eclipse plugins from Liviu support OpenOCD and Segger J-link, so with this update or extension it adds P&E support to it. With this, I can use the P&E debug devices (P&E Multilink, Tracelink) or as well the Freescale OpenSDA with it.
PnE Debug Interfaces
I *love* the Freescale Freedom boards, and you probably recognized that with all my projects using them. The Freedom boards are small, inexpensive and can be easily extended with Arduino shields which makes them a great platform for prototyping. But sometimes I just need an ARM microcontroller with some headers, and then the 85mm x 55mm size of the Freedom board is not ideal. That’s nothing new, but I realized that yet again when I did my Adafruit NeoPixel clock: the FRDM board was rather bulky, even if hidden behind that clock. I need something much smaller: the Teensy board!
Size Comparison FRDM vs. Teensy
I admit: I love command line interfaces. Because that gives me usually much more control than any GUI (Graphical User Interface). I like the fact that they have put a UART interface on the RIoT board:
J18 UART on the RIoT Board
For my boot loaders I need the functionality that I can keep memory ranges from being erased while downloading the rest of the application. P&E provides a GDB server which interfaces with their probes (P&E Universal Multilinks, Tracelinks, …) and as well with the OpenSDA present on many of the Freescale evaluation boards. In CodeWarrior there is an option for ‘Advanced Programming Options’ which allows to preserve memory of the microcontroller FLASH (see “Programming part of flash“). However, that option or button is not present in the Eclipse version of the P&E GDB server (e.g. in Kinetis Design Studio). So how can I preserve some areas of FLASH in Eclipse with GDB?
Preservation of Non-Volatile Memory in CodeWarrior
I had great plans for this Saturday: to work on really cool project. But as so many times, things turned out to be different. Maybe you have read my recent posts about printf()? A colleague wanted to use that article to the same thing with the Kinetis Design Studio on the FRDM-K64F board. I used the FRDM-KL25Z board, so I expected this to work out of the box for him too. Well, turned out that I was wrong about this, and my Saturday was used for debugging and googling about a printf() problem 😦
While things work as expected for the FRDM-KL25Z (ARM Cortex-M0+) and using the standard GNU GCC ARM Embedded from the launchpad, the application traps on the K64F (ARM Cortex-M4F) in initialise_monitor_handles() with KDS:
Trap in initialize_monitor_handles()
While new Freescale boards come with the OpenSDA debug firmware, I still students using boards with the OSBDM/OSJTAG. And with new CodeWarrior tools, it might be that there is a new OSBDM/OSJTAG firmware, and when I download to a board with an older firmware, the tool will prompt me to update the firmware. To me, after doing this several times, not a big deal. But for someone who sees this the first time, it might not be that easy. So to avoid any further questions, here we go with a step-by-step tutorial how to update the OSBDM/OSJTAG firmware.
MCF52259 Tower Board with OSBDM Firmware
MCU on Eclipse 