Without emulator SMS reply is not coming.

You need to distinguish two cases here:
1) The program behaves differently depending on whether you stop at a breakpoint (somewhere) vs you let it free-run. This is most likely your code failing to wait for something to complete (the breakpoint gives it time to complete).
2) The program behaves differently depending on whether the debug FET is connected or not. The first guess here is power -- the FET provides a fairly hefty power source, where your unit's own power source may be weaker.

Guessing you're seeing (2): Cell modems are notorious power hogs, and their requirements tend to be bursty. You should make sure your power source is up to what the modem's data sheet requires (including peaks).

What exactly is the "Ack"? Is that the "OK" from the AT command that sends the SMS, or is it a reply that you build?

Hello Bruce,

1) The program behaves differently depending on whether you stop at a breakpoint (somewhere) vs you let it free-run. This is most likely your code failing to wait for something to complete (the breakpoint gives it time to complete).

--> Program is free-run (without debugger) .

2) The program behaves differently depending on whether the debug FET is connected or not. The first guess here is power -- the FET provides a fairly hefty power source, where your unit's own power source may be weaker.

-->   Debugger  Is not connected after loading code into mcu and actually 20 Watt of power supply is used but MCU required 2 Watt , which means here power supppy is not weak.

ACK is build as per requirement of project.

 

Scenario :

   Same code is working on Analog Devices mcu(ADE5169).

    In this scenario , when code is running free (Without debugger ) , Reply of SMS (ACK ) is coming.

Then what is problem on MSP430 MCU? Please reply .. 

 

Regards, 

Sanjay.

 

Then what is problem on MSP430 MCU? Please reply ..

The problem is not with the MSP430, but with your code.

Have you never heard of a method called "code instrumentation" ?

Use an available interface on the MSP430 (e.g. UART), and add code to out put status information during runtime. Watch this status info with a PC, to check/verify it's behavior. It usually requires several iterations (i.e. instrumentation code changes) to pin down the issue.

There' s lots of threads in this forum about "it works with debugger, but does not w/o it". 

Difference of behaviour with/without debugger could be caused by:

1) post-reset sequence/init fails w/o debugger because diferent timing or different VCC power-on slope - debugger usually releases device from reset when power is long reached nominal level, it could not be so when you run circuit w/o debugger/FET. You shall try to manually reset uC (assert RST pin) few seconds after power-on, check how it changes behavior.

2) You use low power mode improperly, debugger suppress it (LPM) so while debugging you don't see problem of required but missing clock for some peripheral. You can temporarily use LPM1 instead of deeper low power mode - to see this is the case or not.