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?
Well, I see that users who never used a debugger and are used to do ‘printf() debugging’ could take advantage of the ‘Run’ function in Eclipse. But why do ‘printf()’ debugging if you have a debugger which is able to solve the real problems. Printf() debugging is like driving a car handcuffed ;-). Or how can someone seriously develop a firmware without a debugger?
So I was kind of happy to see that both the GNU ARM Eclipse plugins and Kinetis Design Studio do not offer a ‘Run’ function. CodeWarrior for MCU has ‘Run’ implemented, see “Comparing CodeWarrior with Kinetis Design Studio“. And guess what? I received questions how to do ‘Run’ with Kinetis Design Studio ;-).
Emulating ‘Run’ with ‘Debug’
So let me jump over my own shadow, and I show how a ‘Run’ can be done with a ‘Debug’ configuration: The differences between ‘Run’ and ‘Debug’ are:
- With ‘Run‘, the application code gets downloaded and the application gets started.
- With ‘Debug‘, the same thing as ‘Run’ happens, except that it usually sets a breakpoint n main() to stop the target there.
So to do the same as ‘Run’ in a ‘Debug’ configuration, I need to set it up that it does not stop at main.
P&E for Run
For the P&E debug configuration, simply disable the ‘Set breakpoint at’ option in the ‘Startup’ tab of the debug configuration:
Segger for Run
Same thing for the Segger J-Link connection: disable that it sets a breakpoint at main:
Terminating the debugging thread
So while the settings above make the program run, there is still one difference between the original ‘Run’ configuration: in the debug view the thread is still shown:
Which is great for me, as I can halt the target and start debugging. However, if I want to do another ‘run’, I need first to terminate the debug session. I can do this with the following settings (Segger J-Link GDB server):
With this, right after the reset, it sends the ‘monitor go’ command to the J-Link to run the target, followed by a ‘disconnect’ which terminates the Eclipse debugging session:
Now I can load the program to the board, it runs the application and automatically disconnects the debugger.
It is possible to emulate the ‘Run’ configuration with a modified ‘Debug’ configuration. Basically it simply means not to set a breakpoint and run the target. To extend this with disconnecting from the target, this requires extra gdb or monitor commands, and I was able to make it work for example with the Segger J-Link.
Happy Running 🙂