Trouble reading memory

Dustin,

Have you tried increasing the stack size?

Do you get this same error when running a simple hello project?

What toolchain are you using and what MSP430 device are you developing with?

Best regards,

Austin Miller

Dustin,

Obviously this is not a common error or bug that we can tell you how to fix. If you could include your code or at least tell us what your code is trying to do that would help. The more information you give, the easier it is for us to help you. Screenshots, code attachments, summary of the goals of your code and device type are all welcome information.

It's possible that your device is resetting. This affects the JTAG connection.

Dustin Lane said:

Also, I'm trying to fill my RAM with a specific value so that I can tell if the stack is overflowing, any suggestions on how to fill the entire RAM with, say a value of 0x1234?

RAM is just a memory location as every other. And C is a memory-based language.

Simply create a pointer to the address oyu want to write to and write to it.

int * memory = RAM_START_ADDRESS;

*memory = 0x1234; // writes 0x34, 0x12 to RAM_START_ADDRESS and RAM_START_ADDRESS+1
memory++; // increases memory by one element size. since the pointer is INT sized, it increawes the address memory points to by 2.
*memory = 0x1234; // writes 0x34, 0x12 to RAM_START_ADDRESS+2 and RAM_START_ADDRESS+3

Don't forget, that your initialized variables as well as the stack and also perhaps the memory poitner itself may reside in RAM and will be overwritten.
So you should start and end the write in the area after your variables and before the reseved stack area begins.
The symbols to use for the end of used variable space etc. depend on the toolchain you use (I can tell you only for mspgcc compiler)

Hi,

 

Dustin Lane said:

Also, I'm trying to fill my RAM with a specific value so that I can tell if the stack is overflowing, any suggestions on how to fill the entire RAM with, say a value of 0x1234?

 

You can use the Memory Fill option with IAR and CCS. Define the start adress, the length and the value.

 

Best Regrads,

AES

Thanks for all the inputs guys.  The memory fill option was very useful, I didn't know about that.  After watching the stack with the memory fill technique, I may have been overflowing at occasion, so I did increase to a safe amount.

A little more information, I am using the msp430F5437A and CCS as my IDE.  My project is relatively large and I haven't been able to pin down any one area where I think the problem may be originating from, so I'm not sure what to provide in terms of example code.

One thought I had, let me know if you think this is valid, is that I am not using a full JTAG programming setup.  Instead I am using the 4 pin SBW connection.  Is it possible that this is a less reliable means of debugging?  I have noticed that while trying to debug and step through my program that it will write random values to some of my watch variables, but yet on the next cycle will write them back to their original value, so I am wondering if this is a problem with SBW...

 

Thanks again!

Dustin,

After your last post I am not sure how you have implemented a 2-wire Spy-Bi-Wire debug interface using 4 pins (wires)?

You may want to reference the following guide: MSP430 Programming Via the JTAG Interface User's Guide.

Specifically Section 1.2.3 Spy-Bi-Wire (SBW) Timing and Control on page 10.

If you could get your hands on a TI MSP430F5438 Experimenter's Board to verify hardware we could eliminate the debugging interface as the source of the problem.

Best regards,

Austin Miller

Increase the stack size does not hurt, but may not help. You may have hidden problems such as recursive calls. The fact that you found the stack is much bigger than you expect is a strong hint of such problems.

 

Dustin Lane said:

I am not using a full JTAG programming setup.  Instead I am using the 4 pin SBW connection.  Is it possible that this is a less reliable means of debugging?

partly. SBW is slower than JTAG, but otherwise identical. In fact, SBW is jsut a parallel-to-serial converter for the original JTAG signals and ends up at the same internal circuitry. So for each JTAG tick, SBW requires three with changing data direction, but otherwise they are identical.

Dustin Lane said:

I am wondering if this is a problem with SBW...

Not with SBW itself. But maybe with your physical connection (bad contacts or voltage problems). Or a bug in the debugger. :)