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.
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?
Best regards,
Ibukun
Certainly. Their values when looping are:
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!