• State Resolved
  • Locked Locked
  • Replies 4 replies
  • Subscribers 53 subscribers
  • Views 1571 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Original question:

Compiler/MSP430FR6989: Behaviour of _assert when no debugger is connected

Compiler/MSP430FR2433: assert() when debugger is used, overriding definition of _abort_msg()

lloyd konneker
Expert 1790 points

Part Number: MSP430FR2433
Other Parts Discussed in Thread: ENERGYTRACE

Tool/software: TI C/C++ Compiler

Some questions and comments related to the linked post.

When assert() is called and you ARE debugging (say a Launchpad, and using the debugger, even when no breakpoints set), I find that assert() ends up pausing the target, and shows a stack trace of:

__TI_writemsg(),  HOSTWrite(). fputs(), _abort_msg(), assert()

and the program counter is at this line of __TI_writemsg():

for (i = 0; i < 8; i++)      PACKCHAR(*parm++, p, i);

I don't understand how that invokes the debugger, but  I don't really care, as long as it breaks into the debugger as if BKPT was invoked.

What I do care about is that these functions don't  have any useful effect, but they seem to drag in a lot of code such as write() and _stream from the runtime library.  And they drag in many variables in the .data segment which seem to get initialized at C startup.  Which very slightly skews memory sizes and power use while using EnergyTrace.

Question: if I don't care to have an abort message, is overriding the definition of _abort_msg() the conventional way?  And how would I then invoke the debugger?

For a production build, I substitute an implementation of assert() that typically does a software reset.

I am testing LPM4.5, use C++, and use many assertions.  Maybe that case is unusual.

  • 0
    TI__Guru**** 253480 points

    The assert macro is required by the ANSI standard for C.  It tests the given expression, and if it is zero, a message is output and the program exits. 

    The TI implementation of assert calls the standard C I/O functions fputs and fflush to output the message. These functions, in turn, call many other functions in the compiler RTS library.  The lowest level of these functions depends on a breakpoint in CCS to work.  For further details on this point, please search the MSP430 compiler manual for the sub-chapter titled Device-Driver Level I/O Functions.

    lloyd konneker said:
    if I don't care to have an abort message, is overriding the definition of _abort_msg() the conventional way?

    No.  The ANSI standard also requires that the implementation of assert refer to the macro NDEBUG.  If NDEBUG is defined, then the assert macro is defined to do nothing.  Typically, NDEBUG is defined on the compiler command line with --define=NDEBUG.

    Thanks and regards,

    -George

  • 0 in reply to George Mock
    Expert 1790 points

    I will read the material you suggest, thanks.

    I already knew about NDEBUG, but I don't want to remove the all the assertions (and I don't want to use exceptions).  (I posted a related post about the fact that DriverLib defines NDEBUG improperly.)

    I don't want to remove assertions but I also don't want an assert to do any io (because it drags in code which has no effect.)  I assume _abort_msg() calls the io functions you refer to.  In the context of an embedded system, an abort message to the host might not make sense (there might not be an OS or other processes or a user who cares about the abort or a programmer running a debugger with a console.)  I want the assert to break into the debugger or do a software reset. I think that it is more or less conventional for one to redefine _exit() (which exits to the host) which also might not make sense for an embedded application.  A quick search doesn't show it is conventional to redefine _abort_msg(), but I suppose I should just try it.

  • 0 in reply to lloyd konneker
    Expert 1790 points
    My idea to redefine _abort_msg() is misguided. I should just redefine the assert macro to do what I want.

    _op_code(0x4343); // break into debugger if EEM is active, otherwise NOP
    PMM_trigBOR(); // DriverLib function to software reset

    The fact that the C standard defines the behaviour that TI implements (write to stderr, then call abort()) is no defense. The C standard fails to say what happens if there is no stderr stream. I suppose it is "undefined behaviour" if there is no stderr. So the TI implementation can do anything when there is no stderr and it is only fortuitous luck that the TI implementation breaks into the debugger when there is no stderr stream.
  • 0 in reply to lloyd konneker
    TI__Guru**** 253480 points

    lloyd konneker said:
    I should just redefine the assert macro to do what I want.

    That seems like a reasonable approach.

    Thanks and regards,

    -George