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.

Startup problem: ESM Group 3 error in sys_startup.c

Other Parts Discussed in Thread: HALCOGEN, TMS570LS1227

Hi,

I'm using HALCoGen code to boot up a simple program to communicate with the PC over sci/lin.  Previously I have been able to get to main() without issue.  Currently the cpu is hanging on lines 224-226 of sys_startup.c.  The comment above the code section refers to esm group 3 errors.  I haven't intentionally changed anything that should effect the startup sequence, yet here I am.  The attached zip file has the HALCoGen config files and a copy of sys_startup.c.

Can anyone tell me what would cause this error?

Setup...

CPU: TMS570LS1227

Kit: DRV8301-LS12-KIT

HALCoGen: 03.05.02

2514.Archive.zip

Thanks,

Mike

  • ... and of coarse, how to fix the problem!

  • Michael,

    You can view the ESM register in the CCS registers window.  Expand the esm group.  The status for group 3 will be nonzero.

    Make note of which bit is set then write ffffffffh to clear the reg.

    Reset and system reset and you should get to main.  You can lookup the error bit that was set to find the source.  

    Or..  you can disconnect CCS, do a porrst, and reconnect.  Only power on reset clears the esm status.

  • ...additionally:

    I can still run the FOC demo (though the first time I tried to run after the initial occurrence of this problem, I did have strange issues that went away with full power on/off).

    When I go to debug my app, it loads then the debugger window says running...

    When I hit Suspend in the debugger it sometimes show the code stuck in the for loop on lines 224-226 of sys_startup.c. Sometimes Suspense will show the disassembly at address 0x00000004....

    Looking at the ESM registers (see below):
    Esm->Stat1 = 0x00000000
    Esm->Stat2 = 0x00010000
    Esm->Stat3 = 0x00000008

    -Mike

  • Anthony,

    If I write 0xFFFFFFFF in the register window of CCS and do a restart in CCS, I get back to the same spot in sys_startup.c.  

    If I modify sys_startup.c to do the writing...

        if ((esmREG->ESTATUS1[2]) != 0U)    {

            esmREG->ESTATUS1[2] = 0xFFFFFFFF; 

        }


    then the cpu gets caught in sys_selftest.c...

        /* wait until memory self-test done is indicated */

        while ((systemREG1->MSTCGSTAT & 0x1U) != 0x1U)



    -Mike


  • Mike,

    Would you please let me know a few things.

    1) What hardware are you using (TI kit or your own custom board.)

    2) What is the part # / silicon revision on the board that you are debugging?

    3) If the board is custom, what do the VDD core & IO voltages read?   What is the clock frequency?

    4) If the silicon revision is not A - then what value do you see in the MSTCGSTAT register when you inspect it with CCS.

    Thanks and Best Regards,

    Anthony

    EDIT: Hi Mike, I see you already answered most of these questions in your first post.  I'll try to contact you this afternoon to discuss.

  • Anthony,

    I'm using the DRV8301-LS12 kit.  The part # is TMS570LS1227AZWTQQI.

    I've noticed a couple of things...

    1) frequently the cpu gets stuck at 0x00000004.

    2) the int vectors are all 0xFFFFFFFF, like they got erased, but not programmed.

    3) the info box that pops up while programming says...".text:0 of 22944 at 0x20".  The FOC demo says ".text:0 of xxxx at 0x0"

    I'm building the code generated by HALCoGen (except sys_main.c) in a library, then linking it to my own sys_main.cpp.  If I move the sys_intvect.asm out of the library folder and into the folder with sys_main.cpp, the info box says at 0x0, the vectors are programmed with something other than 0xFFFFFFFF, and the problem goes away.

    Does this make sense?  That the sys_intvect.asm file needs to be compiled with the sys_main.cpp and not in a library?

    Thanks,

    Mike

  • Mike,

    I think if you link with just the runtime support library that ships with the compiler, and no HalCoGen, you get interrupt vectors full of 0xFFFFFFFF.

    So, if seeing the vectors as 0xFFFFFFFF isn't 'intermittent' but you have to rebuild or reflash to see them change, then I would think the issue is probably the order in which you are linking.   You'll need to make sure your HalCoGen library is on the link command line before the runtime support library so that the vector table gets pulled from it and not the RTS lib.

    Not sure how this would result in some of the other issues, though. 

    Best Regards,

    Anthony