• State Resolved
  • Locked Locked
  • Replies 6 replies
  • Subscribers 53 subscribers
  • Views 727 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.

CCS 5.4 - F28M35 - Processor shows as "Running" upon load

Wil P.
Expert 1660 points


As soon as I load my out file on the M3 core of this processor, it immediately goes to Running.  It does not stop at the first line anymore.  

Between when the code last worked and now, I was messing around quite a bit with the shared RAM using the CMD file.

Any idea what I broke?  Is there anything I can do besides reverting to an old version of code and rebuilding the changes?

Obviously, the code compiles fine, and the MAP files does not appear to be stomping on anything.

CCS 5.4.0.00091

  • 0
    Guru 92251 points

    William Perdikakis said:
    As soon as I load my out file on the M3 core of this processor, it immediately goes to Running.  It does not stop at the first line anymore.  

    That normally means the processor is crashing during the C run-time library start-up prior to main being called.

     By default CCS is set to run the program to main upon download. If you go to CCS Project Properties -> Debug -> Auto Run and Launch Options -> Auto Run Options and untick the "On a program load or restart" when the program is downloaded it stop at the processor reset vector. You can single step through the C run-time library start-up to find where the crash is occuring. This is a bit tedious since usually no symbolic information and you have to single step the assembler.

  • 0 in reply to Chester Gillon
    Expert 1660 points

    Yikes!

    This thing goes into 0x1001566, then jumps around like crazy. I have NFI what is going on.

    0x1001566 -> 0x1002338 -> 0x10015AE  Then ends up returning to 0x10015AE.

    Does this mean anything to you?

    Two things I learned today:

    1. Never promise crazy a baby. (Irrelevant to this thread, don't ask)
    2. No change is "too small" to worry about.
  • 0 in reply to Wil P.
    Guru 92251 points

    I am not familar with a F28M35, can you post your linker .cmd and .map files, as they might give a clue about those addresses.

  • 0 in reply to Chester Gillon
    Expert 1660 points

    Before I posted this, I looked in these files.  Nothing is at those addresses that I can see, but you probably understand the system better than I do.

  • 0 in reply to Wil P.
    Guru 92251 points

    William Perdikakis said:
    This thing goes into 0x1001566, then jumps around like crazy. I have NFI what is going on.

    0x1001566 -> 0x1002338 -> 0x10015AE  Then ends up returning to 0x10015AE.

    Does this mean anything to you?

    OK, this is the first time I have looked at how a F28M35 boots the Cortex M3 core. From looking at the data sheet and Technical Reference Manual now realise that at the M3 processor reset starts executing code from the M-Boot ROM, which is dual-mapped to the address ranges 0x00000000 – 0x0000FFFF and 0x01000000 – 0x0100FFFF. i.e. the covers the address range you reported.

    The M3 user code is stored in flash with the entry point at address 0x00200030, where the M-Boot ROM transfers control to the address 0x00200030 in flash . Therefore, if you need to start single-stepping the C run-time start-up code will have to set a breakpoint at address 0x00200030 and run to that breakpoint following a processor reset.

  • 0 in reply to Chester Gillon
    Expert 1660 points

    Ok, it turns out that this particular line blows the program up:

    #pragma DATA_SECTION(FaultFlags_GeneratorControl_c28, "FF_GenControl");

    I made a post on the C2000 forums since it seems to be Concerto specific. http://e2e.ti.com/support/microcontrollers/c2000/f/171/t/272832.aspx

    Thanks