Question: How can you distinguish an embedded programmer from a non-embedded programmer just by looking at his debugger?
Answer: The embedded programmer has at least one Memory View open, while the non-embedded programmer probably does not care.
Well, this is maybe a too simplistic answer, but I think it has some truth. An embedded system programmer cares a lot about the memory of his system, and so do I. My post on flash programming was the aspect of permanently programming the memory. This one is is about RAM and Flash.
I want to see where things are in memory. I want to see it in many different formats. Yes, I’m using as well the other views the debugger is offering (call stack, local and global variables, etc) too. But beside of the Registers View, the Memory View is the one I always need.
The Registers View and the Memory View are the heart and foundation of everything you see in your debugger, so you depend on them. Most of the information you see in the debugger is based on memory and registers. With highly optimized compilers, the Variables View might not show always the reality on the core.
Being myself a compiler engineer, I know that keeping track of the debugging information during all the optimization stages is a real challenge. And I know that engineers including myself are sometimes a bit lazy. So when I’m in doubt about the information presented in the debugger, I consult the Registers and Memory View.
I’ll put the Registers and Variables view aside for now: that might be a good topic for another post. So let’s have a look at the memory. CodeWarrior comes with two different Memory Views:
- the Memory Browser View
- and the Memory View.
The Memory Browser View is a very simple and straight forward one: enter an expression and it will show the memory:
You can configure it for the usual things: what to show, in which format (hex, decimal, endianess, ASCII, etc).
If you want to see the memory at an address: simply enter that address. The cool thing is that it supports as well expressions: if you want to see the a variable in memory, you simply use the variable name with the & address operator:
The view has two toolbar icons on the right hand side which allows you to import and export memory:
The other cool thing with the Memory Browser is: if you are using a microcontroller with a Harvard Architecture (e.g. the Freescale Digital Signal Controllers) in CodeWarrior, then it will offer automatically the different memory spaces as supported by the architecture:
Note: Eclipse CDT has an issue with addressable data size greater than 1. On some architectures (as the Freescale DSC) you have special memory which is word-addressable only. The workaround is to use the Memory View in Hexadecimal mode.
Many times you want to see the memory for a variable. An easy way to do this is to use the View Memory context:
This will show the variable in memory using the Memory View:
The Memory View is the extended and enhanced version of the Memory Browser View: It has the concept of Renderings: You can display the memory from a base address in different ways. You can switch easily between hexadecimal and decimal or binary renderings. You have on the left hand the different locations (monitors) in memory you want to watch. It allows you as well rendering the memory in Disassembly form: This is especially valuable if you run code in RAM e.g. to program the flash memory by the application.
Adding a new monitor is easy: click on the ‘+’ icon and fill in the information required. As you can see, you are not limited to the address: you can specify variables with expressions as well:
Using the Format… context menu will give you options to change the look and feel:
Another feature specific to CodeWarrior is the ability to refresh the memory while running (Live View):
With this it is possible that the memory gets updated while the target is running. That might be intrusive depending on your target and run control capabilities. But it is incredible useful to see how a counter in memory is changing over time. See Tom’s post on this really great feature.
With this, I hope you have some good ideas how to use the different Memory Views in eclipse and CodeWarrior for MCU.