RAM to Flash copy error in F28069 bootloader

Hi Karen,

It does not appear you are using TI-RTOS, so I've moved your thread to the device forum.

Todd

Karen,

I will request the software team in C2000 to look why example code provided in controlSuite isn't compiling. Will have some one get back with you.

Regards,
Manoj

Karen,

can you check if DELAY_US is part of the RAMFUNCS?

Best Regards

Santosh Athuru

Hi Todd,

I'm not using TI-RTOS. Thanks for catching that!

Thanks,
Karen

Hi Santosh,

I believe DELAY_US is part of ramfuncs. In F2806x_usDelay.asm, I see the following:

.def _DSP28x_usDelay
.sect "ramfuncs"

.global __DSP28x_usDelay
_DSP28x_usDelay:
SUB ACC,#1
BF _DSP28x_usDelay,GEQ ;; Loop if ACC >= 0
LRETR

In F2806x_Examples.h, DELAY_US is defined using DSP28x_usDelay

#define DELAY_US(A) DSP28x_usDelay(((((long double) A * 1000.0L) / (long double)CPU_RATE) - 9.0L) / 5.0L)

The first function called in main is MemCopy((Uint16 *)&RamfuncsLoadStart, (Uint16 *)&RamfuncsLoadEnd, (Uint16 *)&RamfuncsRunStart);

RamfuncsLoadStart = 0x3d8002
RamfuncsLoadEnd = 0x3d8d5c
RamfuncsRunStart = 0x8000
The location of DSP28x_usDelay is 0x8d56, so it looks like it's one of the last bits of code being copied into RAM when MemCopy is called.

When compiling, there's a warning that "entry-point symbol other than "_c_int00" specified: "_code_start_n".

Karen,

thanks. can you check two things?

1> can you step into the DELAY_US call and see if there is valid code getting executed and if the function returns back properly?

2> is watchdog disabled? or enabled?

if you can check if the reset is being caused by watchdog or because of cpu executing invalid code it will help?

Best Regards
Santosh Athuru

Hi Santosh,

1. When I try stepping into the DELAY_US, CCS doesn't step into the function. Instead it freewheels and when I stop it, it's executing the Memcopy called at the beginning of main.

2. The watchdog is disabled (WDCR = 0x40) until the processor executes the line SysCtrlRegs.CLKCTL.bit.OSCCLKSRCSEL = 1; in ConfigureUSB. Then, WDCR reads 0x00. I added in a line to disable the watchdog (writing WDCR |= 0x40) right after than line. However, when I stepped through the code, after I executed that line to set WDCR = 0x40, WDCR wasn't 0x40 -- it was 0x80, which indicates that something is resetting the watchdog. The next line after that is the call to DELAY_US.

I wrote down what WDCR and WDKEY are doing in the comments for ConfigureUSB.

/*part of the code for main*/

void main(void)
{
MemCopy((Uint16 *)&RamfuncsLoadStart, (Uint16 *)&RamfuncsLoadEnd, (Uint16 *)&RamfuncsRunStart);

//Application check and branch
AppCheck();


g_ulCommandFlags = 0;

#ifdef ENABLE_FAILSAFE
g_bFailsafe = false;
#endif

#ifdef BL_HW_INIT_FN_HOOK
BL_HW_INIT_FN_HOOK(void);
#endif

ConfigureUSB();

....

/*part of the code for ConfigureUSB*/

void
ConfigureUSB(void)
{
//
// Enable the main oscillator.
//
EALLOW;
SysCtrlRegs.CLKCTL.bit.XCLKINOFF = 1;
SysCtrlRegs.CLKCTL.bit.XTALOSCOFF = 0;
SysCtrlRegs.CLKCTL.bit.OSCCLKSRC2SEL = 0; //after executing this, WDCR = 0x40, WDKEY = 0x40;
SysCtrlRegs.CLKCTL.bit.OSCCLKSRCSEL = 1; //after executing this, WDCR = 0x00, WDKEY = 0x0;
SysCtrlRegs.WDCR |= 0x40; //I added this -- after executing this line, WDCR = 0x80, WDKEY = 0x80.

//
// DELAY_US while the main oscillator starts up.
//

DELAY_US(10); //this is where the processor gets stuck

Thanks,

Karen

To clarify,

I see the same problem with DELAY_US even if I remove that line setting WDCR |= 0x40 right before DELAY_US is called. Previously, I didn't have the watchdog disable command in, I just threw that in this morning to see if it made a difference. I get the same result either way with DELAY_US.

are you executing this on a 2806x launchpad?

with DELAY_US, you will have to do assembly single stepping and look at the dis-assembly window to see if valid code is being executed. Lets try to confirm this.

or can you call DELAY_US at the beginning of Configure USB function or immediately after the memcpy? this will also make sure that there is nothing wrong with DELAY_US.

The other problem could be with how the clocks are being set up. I'll ask the USB expert to have a look at the function once we rule out the DELAY_US. 

Best Regards

Santosh Athuru

Hi Santosh,

I'm working with the LAUNCHXL-F28069M.

Assembly stepping:

I removed the line disabling the watchdog before DELAY_US is called and then stepped through the assembly when DELAY_US is called. I replaced the line DELAY_US(10) with DELAY_US(1) to speed up debugging, since I'm stepping through the DELAY_US function.

I can step through the assembly in the DELAY_US call. It loops through the BF and SUB commands, as expected, before exiting at LRETR and returning to bl_usb.c. If I step through the assembly for DELAY_US, I can get it to go through the DELAY_US call and then step through the rest of the source code -- until I hit another DELAY_US call. However, if I try to step over the DELAY_US in the c source code, I run into that reset issue. I suspect that something in the way the emulation affects clocking is causing it. I've seen issues before where I was manually stepping through c source that was changing GPIO outputs -- and the GPIO outputs weren't changing as expected. However, if I used the same source and let the debugger free-run, I didn't have problems getting the GPIO outputs to change.

.def _DSP28x_usDelay
.sect "ramfuncs"

.global __DSP28x_usDelay
_DSP28x_usDelay:
SUB ACC,#1
BF _DSP28x_usDelay,GEQ ;; Loop if ACC >= 0
LRETR

Checking DELAY_US:
I put in a DELAY_US(1); statement right after memcopy is called and was able to step over that with no issue. I also threw some DELAY_US statements in and was able to step over them without issue until I hit the call after SysCtrlRegs.CLKCTL.bit.OSCCLKSRCSEL = 1 is executed. After I call that last DELAY_US statement, then the processor returns to the code start.

void
ConfigureUSB(void)
{
//
// Enable the main oscillator.
//
DELAY_US(1);
EALLOW;
SysCtrlRegs.CLKCTL.bit.XCLKINOFF = 1;
DELAY_US(1);
SysCtrlRegs.CLKCTL.bit.XTALOSCOFF = 0;
DELAY_US(1);
SysCtrlRegs.CLKCTL.bit.OSCCLKSRC2SEL = 0;
DELAY_US(1);
SysCtrlRegs.CLKCTL.bit.OSCCLKSRCSEL = 1;

//
// DELAY_US while the main oscillator starts up.
//

DELAY_US(1); //processor resets !!!

//
// Set the crystal frequency, switch to the main oscillator, and enable the
// PLL.
//
// Setup PLL for 80Mhz
// Calculate the appropriate multiplier with the given crystal frequency
while(SysCtrlRegs.PLLSTS.bit.MCLKSTS);
SysCtrlRegs.PLLSTS.bit.DIVSEL = 0;
SysCtrlRegs.PLLSTS.bit.MCLKOFF = 1;
SysCtrlRegs.PLLCR.bit.DIV = 80000000UL/CRYSTAL_FREQ;
while(!SysCtrlRegs.PLLSTS.bit.PLLLOCKS);
SysCtrlRegs.PLLSTS.bit.MCLKOFF = 1;
SysCtrlRegs.PLLSTS.bit.DIVSEL = 3;

Thanks for all your help,
Karen

Hi Santosh,

I checked the Launchpad and the external oscillator isn't populated. Looks like that's the problem.

Thanks,
Karen