It is great if vendors provide a starting point for my own projects. A working ‘blinky’ is always a great starter. Convenience always has a price, and with a ‘blinky’ it is that the code size for just ‘toggling a GPIO pin’ is exaggerated. For a device with a tiny amount of RAM and FLASH this can be concerning: will my application ever fit to that device if a ‘blinky’ takes that much? Don’t worry: a blinky (or any other project) can be easily trimmed down.
Binky on NXP LPC845-BRK Board
I use a ‘blinky’ project here just as an example: the trimming tips can apply to any other kind of projects too.
Looking for a small, inexpensive ($25-30) ARM development board (say 120-180 MHz ARM Cortex-M4 with FPU, 512kB-1MB of FLASH and 256 KByte of RAM? Then have a look at the Teensy 3.5 and Teensy 3.6 by PJRC/Paul Stoffregen:
Teensy 3.5 with NXP K64F ARM Cortex-M4F
The only problem? it is not possible to debug it :-(. At least not in the traditional sense. This article is about how to change the board to use it with any normal SWD debugging tool e.g. Eclipse and the Segger J-Link :-).
Questions from students or readers of my articles are a great source for all kind of articles. And here is the ‘question of this week’: “What is realtime debugging”?
It’s a good question because the topic of ‘realtime’ and ‘debugging’ was a topic in the lectures this week. So this question gives me the opportunity to combine the two things of ‘realtime’ and ‘debugging’, I love it :-).
Sometimes things don’t go well, especially with bringing up a new board design. I always sweat blood that first minute when I try to connect with the debugger to a new design: Will it work? After the optical inspection, performing electrical tests (no shortcuts? voltage levels ok?) the inflection point is when I’m connecting the first time with the debugger to the new board: either it will properly connect and program the device (hurrah!) or it will fail and potentially difficult hours of investigations have to follow.
Starting from the baby steps for our project seems like a good idea but not very helpful though. Learning and understanding Kinetis SDK seems like a lot of work. Meanwhile, I would like to share an important piece of information that I found on my path of working on this project. Many of you might already know, but being a first time user of Kinetis SDK 1.2.0, I found that there are few differences between Kinetis SDK 1.1.0 and Kinetis SDK 1.2.0. I was trying my hands on to use the KDS with KSDK.
So, In order to create a KDS project with Kinetis SDK, I need to create new folders, add different files and the libraries to my project. I didn’t look into all this with much detail before. I would recommend all to go through this link in order to understand using KDS with Kinetis SDK1.1.0 and Kinetis SDK 1.2.0: https://community.freescale.com/docs/DOC-103288
This is how it looks after you have added everything:
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.”
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?