Program load/debug issue. Stuck in loop on program load?

Many thanks Katie.

Katie Enderle said:

Here is how you can get around it: in CCS, you can use a function called __system_pre_init() that is called before your variables all get initialized -

For completeness for others who stumble on this thread, in IAR, this function is called __low_level_init()

// RETURNS:     1    - Causes the C startup code to initialize memory
//              0    - No memory segments are initialized.
//-----------------------------------------------------------------------------
int __low_level_init( void )
{...

Hi Katie

I have the same problem but I am not sure it is because of uninitialized variables. My problem is the program will go to run situation after loading before I click the RUN button!!! The code does not execute properly. I am confused.

How can I disable watchdog before loading. Is there a way to disable it in gel file?

Regards,

Mohsen

Hi Mohsen,

To me this sounds like the same behavior as the large number of uninitialized variables being zero-initialized issue - the watchdog is timing out before you ever get to main(). Note that if you have a large number of initialized variables (not just uninitialized) you'll run into the same problem. The method to disable the watchdog before the variable initialization occurs (to prevent timing out) is exactly the same as discussed above - disable the watchdog in the __system_pre_init or __low_level_init function (depending on CCS or IAR). You can get more information in the other posts that I linked - I'll put the information here again:

Katie Enderle said:

"Please see the C/C++ Compiler Guide here. Section 6.8.1 talks about _system_pre_init() - you can simply override it by making your own. You can find a stub version in the file pre_init.c. There are also some other threads in this forum with examples if you search for _system_pre_init."

Regards,

Katie

Mohsen Taheri said:

...  My problem is the program will go to run situation after loading before I click the RUN button!!! ...

Yes, the program will go to run situation before you click the RUN button.

Normally, a break-point is set up automatically at the beginning of your main(). And the run situation is suppose to do some preliminary work and eventually reach that break-point. Only after that, it waits for the RUN button.

Uninitialized variables do not cause any problem other then the fact that they are uninitialized. It is too much initialized variables that may cause the Watchdog to prevent the run situation to reach that break-point in time (before the Watchdog barks).

There are many other potential problems of this scheme that prevents the run situation from reaching a break-point. This include the possibility that there was no break-point. Did you tell CCS to do so?

Hi Katie

I dont know how to use _system_pre_init() totally.  Could you please send me an example code?

Should I add a new file to my project?

Where does this function place in the main code? after main function or before it?

thanks,

Mohsen

Katie

I do not use CCS so I do not know this for sure. Please see:

old_cow_yellow said:

...  My problem is the program will go to run situation after loading before I click the RUN button!!! ...

Yes, the program will go to run situation before you click the RUN button.

Normally, a break-point is set up automatically at the beginning of your main(). And the run situation is suppose to do some preliminary work and eventually reach that break-point. Only after that, it waits for the RUN button.

Uninitialized variables do not cause any problem other then the fact that they are uninitialized. It is too much initialized variables that may cause the Watchdog to prevent the run situation to reach that break-point in time (before the Watchdog barks).

There are many other potential problems of this scheme that prevents the run situation from reaching a break-point. This include the possibility that there was no break-point. Did you tell CCS to do so?

[/quote]

In addition to a breakpoint at the beginning of main, c-startup is supposed to be loaded as well, and the Reset Vector is supposed to point to c-startup. Thus what Mohsen called run situation should have been running c-startup.

I think Mohsen did not set up CCS correctly to do the above and causes his run situation a problem.

-- OCY

Hi Mohsen,

__system_pre_init() is just a stub function in CCS that you can overwrite with your own version that includes code to disable the watchdog. I've attached an example:

/*******************************************************************************
 *
 *  UserExperience.c - system_pre_init.c
 *
 *  Copyright (C) 2010 Texas Instruments Incorporated - http://www.ti.com/ 
 * 
 *  Redistribution and use in source and binary forms, with or without 
 *  modification, are permitted provided that the following conditions 
 *  are met:
 *
 *    Redistributions of source code must retain the above copyright 
 *    notice, this list of conditions and the following disclaimer.
 *
 *    Redistributions in binary form must reproduce the above copyright
 *    notice, this list of conditions and the following disclaimer in the 
 *    documentation and/or other materials provided with the   
 *    distribution.
 *
 *    Neither the name of Texas Instruments Incorporated nor the names of
 *    its contributors may be used to endorse or promote products derived
 *    from this software without specific prior written permission.
 *
 *  THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS 
 *  "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT 
 *  LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
 *  A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT 
 *  OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, 
 *  SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT 
 *  LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
 *  DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
 *  THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT 
 *  (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE 
 *  OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
 *
 ******************************************************************************/
 
/*
 * The function _system_pre_init it called by the start-up code before
 * "main" is called, and before data segment initialization is
 * performed.
 *
 * This is a template file, modify to perform any initialization that
 * should take place early.
 *
 * The return value of this function controls if data segment
 * initialization should take place. If 0 is returned, it is bypassed.
 *
 * For the MSP430 microcontroller family, please consider disabling
 * the watchdog timer here, as it could time-out during the data
 * segment initialization.
 */
 
#include <intrinsics.h>
#include "msp430.h"

int _system_pre_init(void)
{
  /* Insert your low-level initializations here */

  /* Disable Watchdog timer to prevent reset during */
  /* long variable initialization sequences. */
  WDTCTL = WDTPW | WDTHOLD;   
  
  /*==================================*/
  /* Choose if segment initialization */
  /* should be done or not.           */
  /* Return: 0 to omit initialization */
  /* 1 to run initialization          */
  /*==================================*/
  return 1;
}

old_cow_yellow:

I think what's happening is the same as what MikeH reported at the top of this post and what you mentioned before: if you have a large number of initialized variables (or uninitialized variables when using EABI format because these are initialized to 0 by default in this format), then while these variables are all being initialized before you reach the breakpoint at main, the time can be enough for the WDT to timeout. When that happens the part will reset and start to run through the initialization again, and timeout/reset again, and keep repeating this without ever reaching the breakpoint for main - giving the "run" behavior that Mohsen mentioned. If you use system_pre_init(), this is a function that will be called before the variable initialization begins, so you can disable the watchdog before any variables are initialized and so you won't be caught in this resetting loop.

Regards,

Katie

Katie,

I am aware of the potential problem of Watchdog timeout during c-startup. But I think there is another possibility.

Please try to set up a CCS project for Assembly code only. But do not supply it with any assembly source code. Supply a simple c-source code instead (without too many variables, or even without any variable at all). I think such a  ill-constructed  project might produce the same symptom as Mohsen did.

-- OCY

Hi old_cow_yellow,

I tried going through the CCS new project dialogue as if making an assembly-only project like you suggested: Project > New CCS Project, then selected Empty Assembly-only Project. This creates a project with a template main.asm file. I excluded that file from the project and added a basic main.c file instead. This, however, throws a bunch of compiler errors, so I think it is unlikely to get to the point of debugging with a poorly constructed project like this.

Another possible thing that could happen would be that you can go into a CCS C project and set the debugger settings such that it will not halt at main - if this was done it could also cause the auto-running behavior.

We will have to see what Mohsen replies back with.

Regards,

Katie

Hi Kati

unfortunately I couldn't solve the problem with your direction. The program sticks somewhere that depicted below.

Something weird:

I can load some project properly without any running problem. So I load the correct project and after that I don't click RUN button, rather,  I reload the ill project and everything is OK!!!!  I mean I don't do launch process again.

what causes it?

Thanks

Mohsen

Mohsen,

Let us go back to the original problem. Do you have a lot of variables in that program? As a matter of fact, if you replace it with the following simple do nothing program, I think you will still have the same problem.

void main (void)
{
  WDTCTL = WDTPW | WDTHOLD;
  while (1) { /* do nothing */ }
}

Like you said, the program will go to run situation after loading before you click the RUN button.

If you click the Stop button, will it stop?

After it stops, can you examining the Flash memory at 0xFFE & 0xFFFF? This is the "reset vector". Where does it points to?

Can you disassemble the code where the "reset vector" is pointing to? The code there should be the c-startup code and eventually should call your main(). But does it do that?

I think Kati can help you with how exactly to do the above.

-- OCY

Hi old_cow_yellow

I apologize for my incomplete  information. I should clear that I am using AM3359 Cortex A8 processor not MSP430. So I can not trace your directions in last post.

Should I change this post to another thread or forum?

Mohsen

I have the problem that the code loads OK but the LaunchPad will not start (its a G2553 chip).  If I unplug the USB cable and then replug it the program starts (like its some power on reset thing....).

I am thinking of putting a switch in line with the USB cable to save time and effort of pulling the cable.  Has any one done this and does it work?

Mohsen Taheri said:

I apologize for my incomplete  information. I should clear that I am using AM3359 Cortex A8 processor not MSP430. So I can not trace your directions in last post.

Should I change this post to another thread or forum?

Seriously? You just wasted a bunch of people's time trying to solve a problem and you're not even using the part everyone thought you were? What part of "MSP430 Ultra-Low Power 16-bit Microcontroller Forum" didn't you understand?

I apologize to anyone who thinks those statements are harsh, but we're here helping free of charge, don't waste our time.

Hi Mohsen,

Here is the correct forum for getting help with AM335x devices: http://e2e.ti.com/support/arm/sitara_arm/f/791.aspx Please try posting there, they should be able to give you better help - this forum is focused on MSP430. Hope this helps get you on the right path!

Regards,

Katie

Hi Brian

You are right, sorry. I just searched my problem and I didn't see the title of forum because my problem is related to Codecomposer and I thought my problem is the same as what discussed in this forum.

However, I'm sorry for any inconvenience but I learned a lot  form Katie that would help me to solve my problem. So I didn't wast time of no one.

Thanks,

Mohsen

You may try pull the TEST jumper out and press the RESET button to reset the chip.

With the TEST jumper out I get the message: MSP430: Error connecting to the target: Could not find device (or device not supported)

when I try to download to the LaunchPad.  Where do you read what these jumpers are for?

Thanks for your help.

Operator Problem:

1.  READ the manual:  http://software-dl.ti.com/trainingTTO/trainingTTO_public_sw/MSP430_LaunchPad_Workshop/v2.20/MSP430_LaunchPad_Workshop_v2.21.pdf

On Page 27:

to start downloaded code:
   click on VIEW in menu bar
     select DEBUG
   click on RUN in menu bar
     select Resume

AND, it works.   Thanks for the help that at least kept me going!