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.

TMS320F28377S: PLLs never lock inside of InitSysCtrl()

Part Number: TMS320F28377S
Other Parts Discussed in Thread: C2000WARE, CONTROLSUITE

I am encountering an issue when trying to build for an F28377S device my company has manufactured. The computer where firmware development has been occurring has not had any issues running their builds. However, when we tried setting up development on a new machine (mine), the program/application locks up inside InitSysPll. The function is called as InitSysPll(XTAL_OSC,IMULT_20,FMULT_0,PLLCLK_BY_2); as normal. However, when the multiplier is written, the PLL never locks. It gets stuck in this while loop:

while(ClkCfgRegs.SYSPLLSTS.bit.LOCKS != 1)
{
    //
    // Uncomment to service the watchdog
    //
    // ServiceDog();
}

How can I fix this?

For information, I am using CCS 12 and debugging with an XDS100v2 JTAG probe.

  • Hello Cole,

    Is the new code running on the same board? Have you confirmed that the crystal oscillator is connected to the F28377S device correctly? Based on the parameters given looks like the code expects a 20MHz crystal.

    Best regards,
    Ibukun

  • This is the same code that is running on the board. We just switched from one computer to another. Our board works perfectly until I try building the exact same code. We have not had any issues until we tried switching computers.

  • Cole,

    In this case I would scrutinize the differences in the setup. What is the power supply to the MCU like (5V from USB? Powered by a wall adapter or from PC? Are you properly observing supply sequencing and slew/ramp rate requirements as per the data sheet?)

    Also, even though it was working before, I would want to examine the crystal oscillator circuit as well.

    If you can share more details about the hardware setup, it could help us narrow down the issue.

    Thanks,
    Ibukun

  • Yes. This board works perfectly fine when running a program built on the other guy's machine. It's only when it is built on mine that it breaks. I have no reason to believe anything on the board is not working correctly, as this is a production part we've been making for a few years. Again, the only thing that changed is what computer this is being built from. The old machine was running CCS v6, and I'm on v12, but other than that, nothing has changed.

  • Ah, so this must have been previously built using a much older compiler version.

    #1 - can you confirm if the C2000Ware version you're building against is the same (which is it?). If you're using the same older version of C2000ware, you may need to update to the latest release for CCSv12 and latest compiler support.

    #2 - please share the full clock and PLL setup code.

    Thanks,
    Ibukun

  • The old system was using TI compiler version 6.4.9 and controlSUITE 3.4.7. It has C2000Ware 1.0.6, but I don't think it is configured to use that. I am using compiler version 22.6.0 (LTS) with C2000Ware 5.0.0.

    I am using F2837xS_SysCtrl.c provided by C2000Ware. InitSysCtrl is called right at the top of main(). It disables the watchdog, does a few things, then calls InitSysPll with arguments to perform a 10x clock boost.

    The function runs the following (trimmed past where it locks up):

    void InitSysPll(Uint16 clock_source, Uint16 imult, Uint16 fmult, Uint16 divsel)
    {
        Uint16 SCSR, WDCR, WDWCR, intStatus,  t1TCR, t1TPR, t1TPRH;
        Uint16 t2TCR, t2TPR, t2TPRH, t2SRC, t2Prescale;
        Uint32 t1PRD, t2PRD, ctr1;
        float sysclkToInClkError, mult, div;
        bool sysclkInvalidFreq=true;

        if((clock_source == ClkCfgRegs.CLKSRCCTL1.bit.OSCCLKSRCSEL)    &&
           (imult        == ClkCfgRegs.SYSPLLMULT.bit.IMULT)           &&
           (fmult        == ClkCfgRegs.SYSPLLMULT.bit.FMULT)           &&
           (divsel       == ClkCfgRegs.SYSCLKDIVSEL.bit.PLLSYSCLKDIV))
        {
            //
            // Everything is set as required, so just return
            //
            return;
        }

        if(clock_source != ClkCfgRegs.CLKSRCCTL1.bit.OSCCLKSRCSEL)
        {
            switch (clock_source)
            {
                case INT_OSC1:
                    SysIntOsc1Sel();
                    break;

                case INT_OSC2:
                    SysIntOsc2Sel();
                    break;

                case XTAL_OSC:
                    SysXtalOscSel();
                    break;
            }
        }

        EALLOW;
        if(imult != ClkCfgRegs.SYSPLLMULT.bit.IMULT ||
           fmult != ClkCfgRegs.SYSPLLMULT.bit.FMULT)
        {
            Uint16 i;

            //
            // This bit is reset only by POR
            //
            if(DevCfgRegs.SYSDBGCTL.bit.BIT_0 == 1)
            {
                //
                // The user can optionally insert handler code here. This will only
                // be executed if a watchdog reset occurred after a failed system
                // PLL initialization. See your device user's guide for more
                // information.
                //
                // If the application has a watchdog reset handler, this bit should
                // be checked to determine if the watchdog reset occurred because
                // of the PLL.
                //
                // No action here will continue with retrying the PLL as normal.
                //
                // Failed PLL initialization is due to any of the following:
                //      - No PLL clock
                //      - SLIP condition
                //      - Wrong Frequency
                //
            }

            //
            // Bypass PLL and set dividers to /1
            //
            ClkCfgRegs.SYSPLLCTL1.bit.PLLCLKEN = 0;

            //
            // Delay of at least 120 OSCCLK cycles required post PLL bypass
            //
            asm(" RPT #120 || NOP");

            ClkCfgRegs.SYSCLKDIVSEL.bit.PLLSYSCLKDIV = 0;

            //
            // 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)
                {
                    //
                    // Uncomment to service the watchdog
                    //
                    // ServiceDog();
                }
            }
        }

        // trimmed...

    Everything runs normally until the very last while loop where the bit never gets set.

  • Of note: that function is not the same one that executes when compiled with the other machine. It runs the older version, but the logic is still the same. The only real change was to loop up to five times due to an errata.

  • Thanks. Let's take a look at the registers at the point where it is stuck in the loop. Can you show the contents of the following registers?

    • CLKSRCCTL1
    • SYSPLLCTL1
    • SYSPLLMULT
    • SYSPLLSTS
    • MCDCR
    • X1CNT

    Best regards,
    Ibukun

  • Certainly. Their values when looping are:

    • CLKSRCCTL1: 0x00000001 (1)
    • SYSPLLCTL1: 0x00000001 (1)
    • SYSPLLMULT: 0x00000014 (20)
    • SYSPLLSTS: 0x00000000 (0)
    • MCDCR: 0x00000000 (0)
    • X1CNT: 0x00000000 (0)
  • Hello Cole,

    I will try to look into this a little further, but at first glance X1CNT being 0 suggests that the crystal oscillator has failed to start up successfully. If we can compare SysXtalOscSel() with the previous function to initialize the crystal, maybe we can figure out what's going on here.

    Ibukun

  • Hi Ibukun,

    I decided I'd do some digging through the assembly myself. One thing I noticed right away, is that the working version, at the top of _InitSysPll, the DP register is loaded with 0x1748. I'm still reading up on the C28x ISA, but it seems DP is a pointer that you shift left by 6 or 7 to get the true address. Doing so (shift left by 6) gives 0x5D200 which is CLK_CFG_REGS, which would make sense. However, in my compiled version, DP is set to 0x2ef (which would give 0xBBC0 when shifted left) which points to nothing (according to SPRUHX5G)? Just in case, I scanned through the rest of _InitSysPll for MOVW DP, xxxx and none of them are loaded with 0x1748 (or 0xBA4 if the shift was by 7).

    Is it possible the PLL never locks because I'm not actually writing to the correct addresses?

    ---

    I've dug some more, and I think I've found where the multiplier and loop are.

    In my version, DP is set to 0x2ef at 9d91f, the accumulator is loaded with the multiplier (IMULT_20 in SP[16] and FMULT_0 in SP[17]) at 9d925, then the accumulator is stored at 0x1C (however, SPRUHX5G says SYSPLLMULT is at 0x14 and nothing is at 0x1C), then we read the least significant bit of 0x1E (which is AUXPLLMULT; SYSPLLSTS should be 0x16) and loop if it's not set at 9d92a.

    0009d91f        $C$L9:
    0009d91f   761f   MOVW         DP, #0x2ef
    0009d920   02ef
    0009d921   1816   AND          @0x16, #0xfffe
    0009d922   fffe
    0009d923   f614   RPT          #20
    0009d924   7700 ||NOP          
    0009d925   5603   MOV          ACC, *-SP[17] << 8
    0009d926   0851
    0009d927   ca50   OR           AL, *-SP[16]
    0009d928   0ea9   MOVU         ACC, AL
    0009d929   1e1c   MOVL         @0x1c, ACC
    0009d92a        $C$L10:
    0009d92a   921e   MOV          AL, @0x1e
    0009d92b   9001   ANDB         AL, #0x1
    0009d92c   5201   CMPB         AL, #0x1
    0009d92d   60fd   SB           -3, NEQ

    The working version, however, loads the accumulator (IMULT_20 in SP[2] and FMULT_0 in SP[3]) at a26f7, writes it to 0x14 (which is SYSPLLMULT), toggles the least significant bit of 0xE to set PLLEN, then loops based on the least significant bit of 0x16 (which is SYSPLLSTS). Again, at this point, DP is 0x1748.

    000a26f7   5603   MOV          ACC, *-SP[3] << 8
    000a26f8   0843
    000a26f9   ca42   OR           AL, *-SP[2]
    000a26fa   88a9   MOVZ         AR6, AL
    000a26fb   a9a9   MOVL         ACC, P
    000a26fc   afa6   OR           ACC, AR6
    000a26fd   1e14   MOVL         @0x14, ACC
    000a26fe   1a0e   OR           @0xe, #0x0001
    000a26ff   0001
    000a2700        $C$L13:
    000a2700   9216   MOV          AL, @0x16
    000a2701   9001   ANDB         AL, #0x1
    000a2702   5201   CMPB         AL, #0x1
    000a2703   edfd   SBF          -3, NEQ

    .

  • Cole,

    But the register values you posted earlier suggest that the PLL config registers were indeed written correctly. CLKSRCCTL1 = 1 for XTAL, and PLLMULT = 0x14 (20) which should lock the PLL at 400MHz, and the PLL is enabled. Were these values from the working version or non-working version?

    Ibukun

  • I tested my theory right now by uploading the built code and debugging. I think my guess is correct. Looking at the memory window, it seems CCS knows that the clock config registers are at 0x5D200, but if I hover over the ClkCfgRegs variable itself, I can see its being located at 0xBBC8 (as my assembly indicated).

    To answer your question, the values I read were from the non-working build. However, I have a theory.

    What I think has happened is: the registers were wrongly mapped by the compiler to 0xBBC8, which happens to be in RAM (RAMD1). So, when the non-working code wrote 0x14 into SYSPLLMULT, it actually wrote it in the entirely wrong place. In fact, inspecting the memory shows 0x14 being located at 0xBBDC.

    So, when I read back the values to you earlier, they had just appeared to be written correctly because they were written into RAM, and, as such, could be read back. X1CNT appeared to be zero because it was just reading blank RAM.

    Basically, this is a compiler issue, not a hardware issue. The compiler is mapping hardware registers into the wrong addresses.

  • Cole,

    One more thing before I engage our software team on this: can you share the linker command file used? We definitely would like to try to replicate the issue over here.

    Also, do you see any compiler warnings during the compile/link process? If so please share them.

    Thanks,
    Ibukun

  • Ibukun,

    Thank you for your help. I do not get any compiler warnings except those from my own code base. However, I do get these linker warnings:

    warning #10247-D: creating output section "FlashPumpSemaphoreRegsFile" without a SECTIONS specification
    warning #10247-D: creating output section "RomPrefetchRegsFile" without a SECTIONS specification
    warning #10247-D: creating output section "RomWaitStateRegsFile" without a SECTIONS specification
    warning #10247-D: creating output section "DcsmCommonRegsFile" without a SECTIONS specification
    warning #10247-D: creating output section "SyncSocRegsFile" without a SECTIONS specification
    warning #10247-D: creating output section "DacaRegsFile" without a SECTIONS specification
    warning #10247-D: creating output section "DacbRegsFile" without a SECTIONS specification
    warning #10247-D: creating output section "DaccRegsFile" without a SECTIONS specification
    warning #10247-D: creating output section "NmiIntruptRegsFile" without a SECTIONS specification
    warning #10247-D: creating output section "CpuTimer0RegsFile" without a SECTIONS specification
    warning #10247-D: creating output section "CpuTimer1RegsFile" without a SECTIONS specification
    warning #10247-D: creating output section "CpuTimer2RegsFile" without a SECTIONS specification
    warning #10247-D: creating output section "Emif1ConfigRegsFile" without a SECTIONS specification
    warning #10247-D: creating output section "Emif2ConfigRegsFile" without a SECTIONS specification
    warning #10247-D: creating output section "XintRegsFile" without a SECTIONS specification
    warning #10247-D: creating output section "XbarRegsFile" without a SECTIONS specification
    warning #10247-D: creating output section "SciaRegsFile" without a SECTIONS specification
    warning #10247-D: creating output section "ScibRegsFile" without a SECTIONS specification
    warning #10247-D: creating output section "ScicRegsFile" without a SECTIONS specification
    warning #10247-D: creating output section "ScidRegsFile" without a SECTIONS specification
    warning #10247-D: creating output section "SpiaRegsFile" without a SECTIONS specification
    warning #10247-D: creating output section "SpibRegsFile" without a SECTIONS specification
    warning #10247-D: creating output section "SpicRegsFile" without a SECTIONS specification
    warning #10247-D: creating output section "AdcaResultRegsFile" without a SECTIONS specification
    warning #10247-D: creating output section "AdcbResultRegsFile" without a SECTIONS specification
    warning #10247-D: creating output section "AdccResultRegsFile" without a SECTIONS specification
    warning #10247-D: creating output section "AdcdResultRegsFile" without a SECTIONS specification
    warning #10247-D: creating output section "DmaClaSrcSelRegsFile" without a SECTIONS specification
    warning #10247-D: creating output section "ECap1RegsFile" without a SECTIONS specification
    warning #10247-D: creating output section "ECap2RegsFile" without a SECTIONS specification
    warning #10247-D: creating output section "ECap3RegsFile" without a SECTIONS specification
    warning #10247-D: creating output section "ECap4RegsFile" without a SECTIONS specification
    warning #10247-D: creating output section "ECap5RegsFile" without a SECTIONS specification
    warning #10247-D: creating output section "ECap6RegsFile" without a SECTIONS specification
    warning #10247-D: creating output section "PieCtrlRegsFile" without a SECTIONS specification
    warning #10247-D: creating output section "Cmpss1RegsFile" without a SECTIONS specification
    warning #10247-D: creating output section "Cmpss2RegsFile" without a SECTIONS specification
    warning #10247-D: creating output section "Cmpss3RegsFile" without a SECTIONS specification
    warning #10247-D: creating output section "Cmpss4RegsFile" without a SECTIONS specification
    warning #10247-D: creating output section "Cmpss5RegsFile" without a SECTIONS specification
    warning #10247-D: creating output section "Cmpss6RegsFile" without a SECTIONS specification
    warning #10247-D: creating output section "Cmpss7RegsFile" without a SECTIONS specification
    warning #10247-D: creating output section "Cmpss8RegsFile" without a SECTIONS specification
    warning #10247-D: creating output section "InputXbarRegsFile" without a SECTIONS specification
    warning #10247-D: creating output section "DcsmZ1RegsFile" without a SECTIONS specification
    warning #10247-D: creating output section "DcsmZ2RegsFile" without a SECTIONS specification
    warning #10247-D: creating output section "EQep1RegsFile" without a SECTIONS specification
    warning #10247-D: creating output section "EQep2RegsFile" without a SECTIONS specification
    warning #10247-D: creating output section "EQep3RegsFile" without a SECTIONS specification
    warning #10247-D: creating output section "I2caRegsFile" without a SECTIONS specification
    warning #10247-D: creating output section "I2cbRegsFile" without a SECTIONS specification
    warning #10247-D: creating output section "McbspaRegsFile" without a SECTIONS specification
    warning #10247-D: creating output section "McbspbRegsFile" without a SECTIONS specification
    warning #10247-D: creating output section "Emif1RegsFile" without a SECTIONS specification
    warning #10247-D: creating output section "Emif2RegsFile" without a SECTIONS specification
    warning #10247-D: creating output section "Flash0EccRegsFile" without a SECTIONS specification
    warning #10247-D: creating output section "Flash1EccRegsFile" without a SECTIONS specification
    warning #10247-D: creating output section "WdRegsFile" without a SECTIONS specification
    warning #10247-D: creating output section "AccessProtectionRegsFile" without a SECTIONS specification
    warning #10247-D: creating output section "GpioDataRegsFile" without a SECTIONS specification
    warning #10247-D: creating output section "ClkCfgRegsFile" without a SECTIONS specification
    warning #10247-D: creating output section "MemoryErrorRegsFile" without a SECTIONS specification
    warning #10247-D: creating output section "AnalogSubsysRegsFile" without a SECTIONS specification
    warning #10247-D: creating output section "Cla1RegsFile" without a SECTIONS specification
    warning #10247-D: creating output section "Clb1LogicCfgRegsFile" without a SECTIONS specification
    warning #10247-D: creating output section "Clb2LogicCfgRegsFile" without a SECTIONS specification
    warning #10247-D: creating output section "Clb3LogicCfgRegsFile" without a SECTIONS specification
    warning #10247-D: creating output section "Clb4LogicCfgRegsFile" without a SECTIONS specification
    warning #10247-D: creating output section "Clb1LogicCtrlRegsFile" without a SECTIONS specification
    warning #10247-D: creating output section "Clb2LogicCtrlRegsFile" without a SECTIONS specification
    warning #10247-D: creating output section "Clb3LogicCtrlRegsFile" without a SECTIONS specification
    warning #10247-D: creating output section "Clb4LogicCtrlRegsFile" without a SECTIONS specification
    warning #10247-D: creating output section "ClbXbarRegsFile" without a SECTIONS specification
    warning #10247-D: creating output section "EPwmXbarRegsFile" without a SECTIONS specification
    warning #10247-D: creating output section "OutputXbarRegsFile" without a SECTIONS specification
    warning #10247-D: creating output section "Sdfm1RegsFile" without a SECTIONS specification
    warning #10247-D: creating output section "Sdfm2RegsFile" without a SECTIONS specification
    warning #10247-D: creating output section "UppRegsFile" without a SECTIONS specification
    warning #10247-D: creating output section "MemCfgRegsFile" without a SECTIONS specification
    warning #10247-D: creating output section "AdcaRegsFile" without a SECTIONS specification
    warning #10247-D: creating output section "AdcbRegsFile" without a SECTIONS specification
    warning #10247-D: creating output section "AdccRegsFile" without a SECTIONS specification
    warning #10247-D: creating output section "AdcdRegsFile" without a SECTIONS specification
    warning #10247-D: creating output section "CpuSysRegsFile" without a SECTIONS specification
    warning #10247-D: creating output section "DmaRegsFile" without a SECTIONS specification
    warning #10247-D: creating output section "EPwm1RegsFile" without a SECTIONS specification
    warning #10247-D: creating output section "EPwm2RegsFile" without a SECTIONS specification
    warning #10247-D: creating output section "EPwm3RegsFile" without a SECTIONS specification
    warning #10247-D: creating output section "EPwm4RegsFile" without a SECTIONS specification
    warning #10247-D: creating output section "EPwm5RegsFile" without a SECTIONS specification
    warning #10247-D: creating output section "EPwm6RegsFile" without a SECTIONS specification
    warning #10247-D: creating output section "EPwm7RegsFile" without a SECTIONS specification
    warning #10247-D: creating output section "EPwm8RegsFile" without a SECTIONS specification
    warning #10247-D: creating output section "EPwm9RegsFile" without a SECTIONS specification
    warning #10247-D: creating output section "EPwm10RegsFile" without a SECTIONS specification
    warning #10247-D: creating output section "EPwm11RegsFile" without a SECTIONS specification
    warning #10247-D: creating output section "EPwm12RegsFile" without a SECTIONS specification
    warning #10247-D: creating output section "Clb1DataExchRegsFile" without a SECTIONS specification
    warning #10247-D: creating output section "Clb2DataExchRegsFile" without a SECTIONS specification
    warning #10247-D: creating output section "Clb3DataExchRegsFile" without a SECTIONS specification
    warning #10247-D: creating output section "Clb4DataExchRegsFile" without a SECTIONS specification
    warning #10247-D: creating output section "DevCfgRegsFile" without a SECTIONS specification
    warning #10247-D: creating output section "CanaRegsFile" without a SECTIONS specification
    warning #10247-D: creating output section "CanbRegsFile" without a SECTIONS specification
    warning #10247-D: creating output section "GpioCtrlRegsFile" without a SECTIONS specification
    warning #10247-D: creating output section "Flash0CtrlRegsFile" without a SECTIONS specification
    warning #10247-D: creating output section "Flash1CtrlRegsFile" without a SECTIONS specification
    warning #10247-D: creating output section "PieVectTableFile" without a SECTIONS specification
    remark #10205-D: automatic RTS selection:  linking in "rts2800_fpu32.lib" in place of index library "libc.a"

    The linker file is the default 2837xS_Generic_FLASH_lnk.cmd from that older machine, but with some modifications to fit the program into flash. This is the same one the other machine was using:

    // Changed RAM length 05/07/2021
    //
    MEMORY
    {
    PAGE 0 :  /* Program Memory */
              /* Memory (RAM/FLASH) blocks can be moved to PAGE1 for data allocation */
              /* BEGIN is used for the "boot to Flash" bootloader mode   */

       BEGIN               : origin = 0x080000, length = 0x000002
       RAMM0               : origin = 0x000122, length = 0x0002DE
       RAMD0               : origin = 0x00B000, length = 0x000800
       RAMLS0              : origin = 0x008000, length = 0x000800
       RAMLS1              : origin = 0x008800, length = 0x000800
       RAMLS2              : origin = 0x009000, length = 0x000800
       RAMLS3              : origin = 0x009800, length = 0x000800
       RAMLS4              : origin = 0x00A000, length = 0x000800
       RESET               : origin = 0x3FFFC0, length = 0x000002

       /* Flash sectors */
       FLASHA           : origin = 0x080002, length = 0x001FFE    /* on-chip Flash */
       FLASHB           : origin = 0x082000, length = 0x006000    /* on-chip Flash */
       FLASHC           : origin = 0x088000, length = 0x002000    /* on-chip Flash */
       FLASHD           : origin = 0x08A000, length = 0x008000    /* on-chip Flash */
       FLASHE           : origin = 0x092000, length = 0x00FFFF    /* on-chip Flash */
       FLASHF           : origin = 0x0A1FFF, length = 0x008000    /* on-chip Flash */
       FLASHG           : origin = 0x0A9FFF, length = 0x001001    /* on-chip Flash */
       FLASHH           : origin = 0x0AB000, length = 0x001000    /* on-chip Flash */
       FLASHI           : origin = 0x0AC000, length = 0x004000    /* on-chip Flash */
       FLASHJ           : origin = 0x0B0000, length = 0x008000    /* on-chip Flash */
       FLASHK           : origin = 0x0B8000, length = 0x002000    /* on-chip Flash */
       FLASHL           : origin = 0x0BA000, length = 0x002000    /* on-chip Flash */
       FLASHM           : origin = 0x0BC000, length = 0x002000    /* on-chip Flash */
       FLASHN           : origin = 0x0BE000, length = 0x002000    /* on-chip Flash */

    PAGE 1 : /* Data Memory */
             /* Memory (RAM/FLASH) blocks can be moved to PAGE0 for program allocation */

       BOOT_RSVD       : origin = 0x000002, length = 0x000120     /* Part of M0, BOOT rom will use this for stack */
       RAMM1           : origin = 0x000400, length = 0x000400     /* on-chip RAM block M1 */
       RAMD1           : origin = 0x00B800, length = 0x000800

       RAMLS5      : origin = 0x00A800, length = 0x000800

       RAMGS0      : origin = 0x00C000, length = 0x003FF0
       RAMGS1      : origin = 0x00FFF0, length = 0x000002
       RAMGS2      : origin = 0x00FFF2, length = 0x000002
       RAMGS3      : origin = 0x00FFF4, length = 0x000002
       RAMGS4      : origin = 0x010000, length = 0x003FEE
       RAMGS5      : origin = 0x013FEE, length = 0x000002
       RAMGS6      : origin = 0x013FF0, length = 0x000002
       RAMGS7      : origin = 0x013FF2, length = 0x000002
       // RAMGS7      : origin = 0x013000, length = 0x001000
       RAMGS8      : origin = 0x014000, length = 0x001000
       RAMGS9      : origin = 0x015000, length = 0x001000
       RAMGS10     : origin = 0x016000, length = 0x001000
       RAMGS11     : origin = 0x017000, length = 0x001000

    }


    SECTIONS
    {
       /* Allocate program areas: */
       .cinit              : > FLASHB      PAGE = 0, ALIGN(4)
       .pinit              : > FLASHB,     PAGE = 0, ALIGN(4)
       .text               : >> FLASHE | FLASHF,    PAGE = 0, ALIGN(4)
       codestart           : > BEGIN       PAGE = 0, ALIGN(4)
       ramfuncs            : LOAD = FLASHD,
                             RUN = RAMLS0 | RAMLS1 | RAMLS2 |RAMLS3,
                             LOAD_START(_RamfuncsLoadStart),
                             LOAD_SIZE(_RamfuncsLoadSize),
                             LOAD_END(_RamfuncsLoadEnd),
                             RUN_START(_RamfuncsRunStart),
                             RUN_SIZE(_RamfuncsRunSize),
                             RUN_END(_RamfuncsRunEnd),
                             PAGE = 0, ALIGN(4)

       /* Allocate uninitalized data sections: */
       .stack           : > RAMGS0     PAGE = 1
       .ebss            : > RAMGS4     PAGE = 1
       .econst          : > RAMLS5     PAGE = 1
       .cio            : > RAMGS8     PAGE = 1
       .esysmem         : > RAMLS5     PAGE = 1

       /* Initalized sections go in Flash */
       .switch             : > FLASHB      PAGE = 0, ALIGN(4)
       .reset              : > RESET,     PAGE = 0, TYPE = DSECT /* not used, */

    #ifdef __TI_COMPILER_VERSION
       #if __TI_COMPILER_VERSION >= 15009000
        .TI.ramfunc : {} LOAD = FLASHD,
                             RUN = RAMLS0 | RAMLS1 | RAMLS2 | RAMLS3 | RAMLS4,
                             LOAD_START(_RamfuncsLoadStart),
                             LOAD_SIZE(_RamfuncsLoadSize),
                             LOAD_END(_RamfuncsLoadEnd),
                             RUN_START(_RamfuncsRunStart),
                             RUN_SIZE(_RamfuncsRunSize),
                             RUN_END(_RamfuncsRunEnd),
                             PAGE = 0, ALIGN(4)
       #endif
    #endif

       ramgs0           : > RAMGS0,    PAGE = 1
       ramgs1           : > RAMGS1,    PAGE = 1

       /* The following section definitions are for SDFM examples */
       Filter1_RegsFile : > RAMGS1,    PAGE = 1, fill=0x1111
       Filter2_RegsFile : > RAMGS2,    PAGE = 1, fill=0x2222
       Filter3_RegsFile : > RAMGS3,    PAGE = 1, fill=0x3333
       Filter4_RegsFile : > RAMGS4,    PAGE = 1, fill=0x4444
       Difference_RegsFile : >RAMGS5,     PAGE = 1, fill=0x3333
    }

    /*
    //===========================================================================
    // End of file.
    //===========================================================================
    */

    Comparing the unmodified version of this file from the old machine against the one my C2000Ware provides, I see a few changes have been made with the "RAM funcs" portions, but not much else.

  • Cole,

    Looks like you are missing F2837xS_Headers_nonBIOS.cmd in your project. This file is in the device_support/f2837xs/common/cmd directory, and should be added either to the include list under Project Properties > Build > C2000 Linker > File Search Path, or simply added directly to the project. This file is required for the bitfield register definitions to work correctly.

    Best regards,
    Ibukun

  • Ah. I found it under C:\ti\c2000\C2000Ware_5_00_00_00\device_support\f2837xs\headers\cmd. It does look like what I need. Adding it to the linker search paths removed the linker warnings!

    I uploaded the new build, and I was able to successfully step over the InitSysPll function call! Thank you for your help!