Memory is everything

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.

Memory View in CodeWarrior for MCU

Memory View in CodeWarrior for MCU

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.

Registers View in CodeWarrior for MCU

Registers View in CodeWarrior for MCU

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.

Variables View in CodeWarrior for MCU

Variables View in CodeWarrior for MCU

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:

  1. the Memory Browser View
  2. 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:

Memory Browser View in CodeWarrior for MCU

Memory Browser View in CodeWarrior for MCU

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:

Using address of variable in Memory Browser

Using address of variable in Memory Browser

The view has two toolbar icons on the right hand side which allows you to import and export memory:

Exporting a memory range to a file

Exporting a memory range to a file

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:

Memory Browser with different Spaces (Code, Data)

Memory Browser with different Spaces (Code, Data)

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:

Variables View with context menu

Variables View with context menu

This will show the variable in memory using the Memory View:

Memory View

Memory View showing different monitors and renderings

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.

Memory View with Disassembly Rendering

Memory View with disassembly rendering

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:

Monitor Memory Dialog

Monitor Memory Dialog to add a new monitor

Using the Format… context menu will give you options to change the look and feel:

Memory View Format

Memory View Format Options

Another feature specific to CodeWarrior is the ability to refresh the memory while running (Live View):

Memory refresh while running

Memory refresh while running

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.

Happy Memorizing 🙂

Advertisements

10 thoughts on “Memory is everything

  1. Pingback: Go, assembly, go! | MCU on Eclipse

  2. Pingback: Show me your files, lib! | MCU on Eclipse

  3. Pingback: A little or big Indian? A Plea for Peace… | MCU on Eclipse

  4. Pingback: Watchpoints: Data Breakpoints in MCU10 | MCU on Eclipse

  5. Pingback: Dump my Device Memory | MCU on Eclipse

  6. None of this works in 10.4. The Memory Browser window pops up, but it is empty, and there is no place to enter an address.

    Same for the View Memory function.

    Like

    • Have you used the ‘Memory Browser’ view (Windows > Show View > Debug > Memory Browser)? There you can enter directly an address.
      For the ‘Memory’ view (without the ‘browser’), you can add a monitor and enter the address.
      It works perfectly for me: I just checked this again in 10.4 (I’m already on 10.5).
      Let me know.

      Like

  7. Pingback: Recovering the FRDM-K64F Bootloader, or: Cloning the Program of a Microcontroller | MCU on Eclipse

  8. Pingback: Show Floating Point Variable Bytes in Eclipse CDT | MCU on Eclipse

What do you think?

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.