Forums

Hi Lisa,

Just to verify what I was doing, I downloaded the msp430fr5739 user experience demo project, built it and launched the debugger - and it worked, right out of the box. I am going to explore the setup and see why this works and nothing else does. Stay tuned...

PEter

Hi Lisa,

Curioser and curioser - not only is the user experience demo still working but I got another simple program debugging correctly. However, I still can't get any of my other programs to debug, so I'm not much further ahead having to do this by rote. There seems to be a problem with loading the program into the debugger - what I have seen is that the debugger tells me that the code was loaded but when I hit Free Run the board is still running the previous program. Which makes sense - if I had previously loaded a non-working program in the debugger when I tried to replace that and the program won't load then I am stuck with a non-working program in FRAM. 

Is there any way to copy the project settings?

More to follow, I'm sure.

Peter

Hi Peter,

at least you have been starting to isolate things.   What is different with your projects?  You can go File->Export and give exporting some settings a try.

Please keep us informed.

Best Regards,
Lisa

Hi Lisa,

It is an interesting, though maddening problem. I think it is the downside of feature expansion where the development environment has gotten complex enough and the hardware small enough that automated setup is absolutely necessary - which hides a good portion of the process. Who would have ever thought that microcontroller development would be like debugging the Windows 3 API?

Perter

Hi Lisa,

Debugging an app with CCS v5.2 and I have set several breakpoints which do show up in the left-most column of the source code while debugging and also in the breakpoints view. The breakpoints always show up as [H/W BP] but the debugger never breaks on them. For instance:

//*****************************************************************************
//
//! \brief Handles SMTP Server Errors

//! \param servResp is the server response
//!
//! \return None.
//
//*****************************************************************************
void smtpErrorHandler(char * servResp)
{
// Currently we don't handle the errors
while(1)
{
__no_operation();
}
}

I put the breakpoint at _no_operation and the debugger just cycles past it.

Any thoughts?

Peter

You're still missing the semicolon.

I'll bite: where?

A commonly encountered but hard to diagnose error is along the lines

struct tag { .... }

main( ... ) { ... }

This actually declares main as returning type "struct tag".  The struct declaration requires a termninating semicolon.

That may not be your problem, but it sort of sounded like it might be.

Hi Douglas,

Good thing to know. Thanks!

All my structs are defined in .lib files and I checked all of them and no joy. Guess I'll have to keep looking.

Peter

I don't know how your "structs are defined in .lib files".  In C source code, the struct declarations must be visible before they can be used.  Often, they are declared in a header (.h) file.  All that a header does is in effect insert its contents in-line into the source where it was #included, so it is as though all the relevant code is embedded in the same C source file.

In one of your earliest posts in this thread, you told Lisa:

Sorry about the confusion - I just didn't bother to copy the entire struct. Here's the entire code:

#ifdef __CCS__
typedef struct __attribute__ ((__packed__)) _handles_descriptor_t
#elif __IAR_SYSTEMS_ICC__
#pragma pack(1)
typedef struct _handles_descriptor_t
#endif
{
unsigned char handle;
unsigned char block_mode;
unsigned short free_bufs;
} handles_descriptor_t;

which is terminated by a ;

There are a number of these files that TI supplies for the EXP430FR5739 experimental board. The architecture is that there are a number of TCP/IP related files that are  compiled and linked into .lib libraries and then linked into the source. Because the .lib files are first in the hierarchy of the build, following the include files for the processor, they do get linked in before the main() code gets compiled.

I still haven't formed any insight into why my debugger won't run to main(). Grrrrrrrr.

Peter

Object libraries don't get linked into the final executable until the final link.  All compilation must be completed before the final link, so main gets compiled before libraries get linked in.  However, I don't think this is relevant to your issue.

Are you sure the program actually got loaded?  If you look at the address of main in the disassembly window, does it look like real assembly code?

What happens if you set a breakpoint in _c_int00 and attempt to load and run?