CCS/TMS320F28377S: Program gets stuck on PLL lock in the initialization

Part Number:TMS320F28377S

Tool/software: Code Composer Studio

I'm creating a complex project from separate different mini-projects tested individually. The project involves external async memory, PWM, Trip Zones, GPIOs, A2D, interrupts, CLA etc. Each part was tested separately. However, the integration project, based on the (randomly chosen) TI "epwm_trip_zone" example, gets stuck in the very beginning. When trying to boot and to debug the solution, the code gets stucks on the line “while(ClkCfgRegs.SYSPLLSTS.bit.LOCKS != 1)” in function InitSysPll(), file F2837xS_SysCtrl.c. This place is called from the very beginning of main() as a part of HW_Init(): main() --> (first call in main() ) HW_Init() --> (first call in HWInit(), unmodified TI code starts here) InitSysCtrl() --> InitSysPll(), and the stuck line in context is:

        // Lock the PLL five times. This helps ensure a successful start.
        // Five is the minimum recommended number. The user can increase this
        // number according to allotted system initialization time.
        //
        for(i = 0; i < 5; i++)
        {
            //
            // Turn off PLL
            //
            ClkCfgRegs.SYSPLLCTL1.bit.PLLEN = 0;
            asm(" RPT #20 || NOP");
 
            //
            // Write multiplier, which automatically turns on the PLL
            //
            ClkCfgRegs.SYSPLLMULT.all = ((fmult << 8U) | imult);
 
            //
            // Wait for the SYSPLL lock counter
            //
            while(ClkCfgRegs.SYSPLLSTS.bit.LOCKS != 1)     // <----------------- This is the problematic line.
            {
                //
                // Uncomment to service the watchdog
                //
                // ServiceDog();
            }
        }

This code is run before that my actual code starts to execute.

This part of the code didn’t change from the last successfully run iteration; there are lots of changes in the code, but they are executed after the initial HW is set up. However, I did modify the linker command file in order to allocate space for code and data sections. At the build time, I receive a lot of messages like “#10247-D creating output section ".Cla1Prog" without a SECTIONS”.

This is (probably) not a HW problem, because “blink” example that initializes HW with the very same functions works on the same hardware correctly.

I've looked into the E2E forums; there are 4 questions on the E2E forums regarding the similar issue, none of them solved. Some answers suggest there is a configuration issue, which is what, I suppose, happens with my project too, but I have no idea what configuration change may cause this issue. I've also had personal correspondence with TI employee C. C---mbo (name obscurified in order to hide possibly personal sensitive information), who advised me to take some actions (his words in italic):

The error you get seems pll not able to lock which normally is an Hw issue o the quartz.  

I doubt this is the case, since I’ve tried the “blink” example on the same hardware, and it works. Up to the point of locking the PLL, there are absolutely no differences in the code between the “blink” example and the project I’m trying to run, (which is based on another example – specifically, “epwm_trip_zone”). If I understand correctly, the fact that “blink” works on the same HW means the problem is not in the code, but in the configuration; however, I don’t understand what exactly in the configuration of the project can lead to this behavior.

 could you put your code inside the blink example ? Just to double check it works there

I’m afraid this would be very difficult. If stripping out the code and inserting it into “blink” project is required for debugging, I’ll do it, but basically it would mean rewriting the integration project.

 Please another test could be to test your sw on launchpad if f2837x 

On the launchpad I have exactly the same error. The “blink” example works there too; the integration project gets stuck at the PLL lock line, just as described above.

I've tried to use internal oscillator instead of the external one in call to InitSysPll(); it didn't change anything.

It’s interesting that if I manually omit the PLL locking with the debugger, I encounter a similar problem later in the initialization sequence, in the following lines: 

    //
    // Initialize and wait for CLA1ToCPUMsgRAM
    //
    MemCfgRegs.MSGxINIT.bit.INIT_CLA1TOCPU = 1;
    while(MemCfgRegs.MSGxINITDONE.bit.INITDONE_CLA1TOCPU != 1){}; <======== Getting stuck here
 
    //
    // Initialize and wait for CPUToCLA1MsgRAM
    //
    MemCfgRegs.MSGxINIT.bit.INIT_CPUTOCLA1 = 1;
    while(MemCfgRegs.MSGxINITDONE.bit.INITDONE_CPUTOCLA1 != 1){}; <=========== And then here

Does it mean that there is some problem with configuration of the CLA memory? The same configuration worked in a separate project. Indeed, I’ve extensively reworked the memory configuration file for the linker. I fully understand that since I omitted the PLL locking, correct boot is not guaranteed, but I need to advance in debugging somehow.

Additional debugging step I've performed is commenting out my code from the integration project, excluding all my .c files but one with the "main()" function and leaving only hardware initialization and "main()", which was modified to just blink the LED on GPIO 31, exactly as the working "blinky" example does. After I did it, the modified integration project keeps being stuck, while the "blinky" project runs Ok.

I've removed the linker command file created by me and used one of the default ones, supplied with the TI C2000 software. It did not change the behavior, - probably the problem is not in the memory allocation.

Next step I'm going to perform is to take the working copy of "blinky" project and try to make it stuck in the same way. Would you please advise me on other ways to debug this problem?