2

I've been searching for why for two hours. Now I'm using IAR Embedded Workbench Evaluation 5.30 to debug on a CC430F6137 dev kit board. As I have declared some global static variable, I realize that I am not able to watch that correctly. They are shown as either FF or 3F.

I tried to look them up in the memory table, the pattern looks like ff 3f ff 3f .... This pattern last from 0x1C00-0x1CFF; Data shown in 0x1D00 - 0x2BFF. According to the datasheet of CC430F6137, the section 0 of the RAM ranges from 0x1C00 - 0x23FF, which is 2KB in total. Section 1 ranges from 0x2400 to 0x2BFF.

For example, on static variable is located at 0x1CED, according to the watch window. However, the value is 0x3F. When I use a local variable to copy the value from that static var, it is however not 0x3F. My static variable falls in a small boundary area(that has the strange pattern) in section 0. My hardware: USB-MSP430 debug interface by TI. The eval board is EM430F6137F900.

I tried the simulator, no problem. I also created a simple piece of code utilizing static variable for MSP430F449 (by TI LPT MSP430 debugger) and the static variables can also be seen. Does anyone have any idea why this happens and possible solutions? THANKS IN ADVANCE!

This bug has been fixed in the newest version of IAR Embedded Workbench

Zhongjie Wu
  • 307
  • 3
  • 12
  • Are you using the "static watch window"? EWB has a separate window for viewing static data. – Clifford Sep 02 '11 at 19:32
  • I tried both the static watch window as well the normal watch window. They all shows FF or 3F. The corresponding address in symbolic memory is also FF 3F pattern – Zhongjie Wu Sep 02 '11 at 19:54
  • 1
    I don't know what is wrong but I can give you some hints on how to track down the problem. First, check the linker map file to ensure that the variables really are placed where there is RAM, and to ensure that the linker and the debugger has the same view of the world. Second, uncheck the box "run to main" and single-step through the cstartup code to verify that it initialized the memory correctly (it should clear the DATA16_Z segment and copy DATA16_ID to DATA16_I). – Lindydancer Sep 13 '11 at 14:16

1 Answers1

1

Here are a few suggestions:

Are you using the RAM disable functionality at all (RAMCTL)?

The RAM memory is made up of n sectors. Each sector can be completely powered down to save leakage, however, all data is lost. Features of the RAM memory include:

• RAM memory has n sectors of 2k bytes each.

• Each sector 0 to n can be complete disabled, however data retention is lost.

• Each sector 0 to n automatically enters low power retention mode when possible.

Any sleep mode in use? I am thinking about LPMx.5.

When LPMx.5 (LPM3.5 or LPM4.5) is entered, the voltage regulator of the Power Management Module (PMM) is disabled. All RAM and register contents are lost.

You wrote:

When I use a local variable to copy the value from that static var, it is however not 0x3F.

Do you mean that the local copy is not 0x3F while the global static is, or that copying makes both the copy and the global static work?

If copying makes both work, I suppose that the static global is never referenced. Make it volatile.

Generate a map file (Project->Options->Linker->List, Generate linker listing, Segment map, Module map). Find the map file in Debug/List and search for your global static variable. It should be in the DATA16_Z section (or possibly in the DATA16_I section, with a related slot in DATA16_ID for the initializing value).

If it is not then you have a problem, I believe you can find interesting info in EW430_CompilerReference.pdf, chapter "Descriptions of segments".

Can you try to write to address 0x1CED from within the debugger? You can use the Memory window to test that, and read back. That would confirm that the memory slot itself is working.

If it does not work, the RAM of your chip maybe damaged. That would explain why you have a pattern within 0x1C00-0x1CFF but not outside of that.

Gauthier
  • 40,309
  • 11
  • 63
  • 97