• State Resolved
  • Locked Locked
  • Replies 2 replies
  • Subscribers 30 subscribers
  • Views 945 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

Software only starting with the debugger on stellaris launchpad ?

Fabien Tregan
Prodigy 20 points

Hi,

  I am new to cortex MCUs, and just started to play with the stellaris launchpad. The board worked as expected with the demo application. Then I tryed to write my code to blink a led : it run fine from CCS when I start debug session, but when I unplug / replug the board, it does not start. I first thought there was a breakpoint on main() entry point (because I uploaded the code in a debug session), so I converted the .out to .bin and flashed with LM flash programmer, but it still does not start.

  I finally tryed to launch the firmware with the debugger and press reset (on the board) without terminating the debug session, and I get "No source available for "0xc00ea5e" "

  In the debug configuration, I checked "run to symbol main -> on a reset"

  What am I doing wrong ? I'd just like my firmware to run when I connect power or reset.

Thank you,

f.

  • 0
    Prodigy 20 points

    update (solved) : I tryed to reproduce the problem by creating a new project, copying my main.c file but not the startup_ccs.c and I hade the same behaviour. Then I copyed the startup_ccs.c from my old project to the new project, and the new one behave as expected (when I reset with during debug session, it stops on first line of ResetISR().

    I still don't understand what went wrong with the first project, but now it is working.

    f.

  • 0 in reply to Fabien Tregan
    TI__Mastermind 26900 points

    I've not actually tried this with CCS but I'm willing to bet this is the reason.  If you left startup_ccs.c out of your project, you would find that the interrupt vector table which includes the initial stack pointer and reset vector, would be missing from your image. The linker would probably still build an image and the debugger may have been able to run it (I assume you were not using interrupts in your first application?) but the CPU would have jumped off into no-man's-land on a reset since the information it needed to start the program wasn't where it was expected.