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.

TMS320C6748: Flashing with large vector

Part Number: TMS320C6748
Other Parts Discussed in Thread: OMAPL138, SYSBIOS, OMAP-L138

I need to create an application that needs a relatively large vector in memory. I am using a board design identical to the OMAPL138 LCDK using a DDR2 of 256MB or so. I am also using the TI RTOS. The application runs well when running using the debugger, at least it is functionally doing what is supposed to do, but fails when I flash it.

I have stripped off almost everything off my program to find the solution to this problem with no luck. Right now, I am using only one source file main.c file and the .cfg file. In this simplified program I turn  ON/OFF two LEDs alternatively. I also define two vectors of a certain size = UPP_BUFFER_SIZE. All I do with these two vectors is to fill them with dummy values in sequence over an over again. Essentially my main.c is shown below, obviating some functions.

When I run this using JTAG (debug mode) I can see both LEDs working as expected, no matter what value I choose for UPP_BUFFER_SIZE, 8192, 16384, 65536 for my two vectors, which are stored in addresses after 0xc0000000, which is DDR as defined in my .cfg file (I think I attached it to this msg). However, when I flash this code into the part I can only seem to make it work when UPP_BUFFER_SIZE < = 8192. It doesn't work for UPP_BUFFER_SIZE>8192 (for instance 8193, 16384, or 65536). I have tried this also on the LCDK observing the same behavior. Why would this code work when I am running using JTAG and not when flashing for UPP_BUFFER_SIZE > 8192? (it does work fine after flashing for UPP_BUFFER_SIZE <=8192). Where is the limitation that seems to want less than or equal to 8192?. I follow the flashing procedure using the out2rc and sfh application to convert app.out into app.bin and later download via UART (along with the boot.ais), which in all cases claims to be successful (no matter what program I download to flash). My .cfg is also there, I am not really using BIOS, so I don't do BIOS_start etc). I do define a stack of 8192 and a heap of 8192 for SYS/BIOS, but that doesn't make a difference as I am not using it (i.e., I increase that and I can't still make it work after flashing when using UPP_BUFFER_SIZE > 8192), also why would it work when running using JTAG but not when flashing?

main.c :

#define UPP_BUFFER_SIZE     16384                 //Dimension in Words Uint16 (16-bit Words)

Uint16 uPPRxBufferI[UPP_BUFFER_SIZE];
Uint16 uPPRxBufferQ[UPP_BUFFER_SIZE];

void main(void) {
    hardware_init();            // init hardware
    Uint32 i=0;
    while (1) {
            LED_ON(4); //turn ON LED 4
            delay(1E6);  //SOME delay with a dummy for loop
            LED_ON(5);//turn ON LED 5
            delay(1e6);
            for (i=0;i<(UPP_BUFFER_SIZE);i++){
                uPPRxBufferI[i]=i;
                uPPRxBufferQ[i]=i+1;
            }

 }
}

//-----------------------------------------------------------------------------
// hardware_init()
//-----------------------------------------------------------------------------
void hardware_init(void) {

    device_init();

}

void device_init(void) {

    //PLL configuration ---------------------------------------------------
    setupPll0(24); // will do 24 MHZ x (24+1) / 2 = 300 MHz SYSCLK1
    //---------------------------------------------------------------------

    //Pin Multiplexing setup ----------------------------------------------
    pinMUX();
    //---------------------------------------------------------------------

    // GPIO SETUP ---------------------------------------------
    // Enable the GPIO Module in the PSC
    gpioPowerOn();
    gpioDirection(); 
   
}


7823.cfg_file.txt
var Defaults = xdc.useModule('xdc.runtime.Defaults');
var Diags = xdc.useModule('xdc.runtime.Diags');
var Error = xdc.useModule('xdc.runtime.Error');
var Log = xdc.useModule('xdc.runtime.Log');
var LoggerBuf = xdc.useModule('xdc.runtime.LoggerBuf');
var Main = xdc.useModule('xdc.runtime.Main');
var SysMin = xdc.useModule('xdc.runtime.SysMin');
var System = xdc.useModule('xdc.runtime.System');
var Text = xdc.useModule('xdc.runtime.Text');

var BIOS = xdc.useModule('ti.sysbios.BIOS');
var Hwi = xdc.useModule('ti.sysbios.hal.Hwi');
var LoggingSetup = xdc.useModule('ti.uia.sysbios.LoggingSetup');
var Clock = xdc.useModule('ti.sysbios.knl.Clock');
var Swi = xdc.useModule('ti.sysbios.knl.Swi');


var Hwi = xdc.useModule('ti.sysbios.family.c64p.Hwi'); // Added when flashing the code to the target
var LoggerSys = xdc.useModule('xdc.runtime.LoggerSys');
Hwi.resetVectorAddress = 0xc0000000;					 // Adedd when flashing the code. It's the place in 
														 // memory where appication will start off

/*
 * Uncomment this line to globally disable Asserts.
 * All modules inherit the default from the 'Defaults' module.  You
 * can override these defaults on a per-module basis using Module.common$.
 * Disabling Asserts will save code space and improve runtime performance.
Defaults.common$.diags_ASSERT = Diags.ALWAYS_OFF;
 */

/*
 * Uncomment this line to keep module names from being loaded on the target.
 * The module name strings are placed in the .const section. Setting this
 * parameter to false will save space in the .const section.  Error and
 * Assert messages will contain an "unknown module" prefix instead
 * of the actual module name.
 */
Defaults.common$.namedModule = false;

/*
 * Minimize exit handler array in System.  The System module includes
 * an array of functions that are registered with System_atexit() to be
 * called by System_exit().
 */
System.maxAtexitHandlers = 4;

/*
 * Uncomment this line to disable the Error print function.
 * We lose error information when this is disabled since the errors are
 * not printed.  Disabling the raiseHook will save some code space if
 * your app is not using System_printf() since the Error_print() function
 * calls System_printf().
Error.raiseHook = null;
 */

/*
 * Uncomment this line to keep Error, Assert, and Log strings from being
 * loaded on the target.  These strings are placed in the .const section.
 * Setting this parameter to false will save space in the .const section.
 * Error, Assert and Log message will print raw ids and args instead of
 * a formatted message.
 */
Text.isLoaded = false;

/*
 * Uncomment this line to disable the output of characters by SysMin
 * when the program exits.  SysMin writes characters to a circular buffer.
 * This buffer can be viewed using the SysMin Output view in ROV.
 */
SysMin.flushAtExit = false;

/*
 * The BIOS module will create the default heap for the system.
 * Specify the size of this default heap.
 */
//BIOS.heapSize = 4096;
BIOS.heapSize = 8192;
/* System stack size (used by ISRs and Swis) */
//Program.stack = 0x400;
Program.stack = 8192;


/* Circular buffer size for System_printf() */
SysMin.bufSize = 128;

/*
 * Create and install logger for the whole system
 */
var loggerBufParams = new LoggerBuf.Params();
//loggerBufParams.numEntries = 4;
//var logger0 = LoggerBuf.create(loggerBufParams);
//Defaults.common$.logger = logger0;
//Main.common$.diags_INFO = Diags.ALWAYS_ON;

System.SupportProxy = SysMin;

/*
 * Build a custom BIOS library.  The custom library will be smaller than the
 * pre-built "instrumented" (default) and "non-instrumented" libraries.
 *
 * The BIOS.logsEnabled parameter specifies whether the Logging is enabled
 * within BIOS for this custom build.  These logs are used by the RTA and
 * UIA analysis tools.
 *
 * The BIOS.assertsEnabled parameter specifies whether BIOS code will
 * include Assert() checks.  Setting this parameter to 'false' will generate
 * smaller and faster code, but having asserts enabled is recommended for
 * early development as the Assert() checks will catch lots of programming
 * errors (invalid parameters, etc.)
 */
BIOS.libType = BIOS.LibType_Custom;
//BIOS.logsEnabled = true;
BIOS.assertsEnabled = true;

LoggingSetup.enableTaskProfiler = true;

/*var clock0Params = new Clock.Params();
clock0Params.instance.name = "clock0";
clock0Params.period = 5000;
clock0Params.startFlag = true;
Program.global.clock0 = Clock.create("&WD_Kick", 5000, clock0Params);*/

//HWI Interrupt for uPP
/*var hwi0Params = new Hwi.Params();
hwi0Params.instance.name = "HWUPP";
hwi0Params.eventId = 94;
hwi0Params.priority = 2;
hwi0Params.enableInt = true;
Program.global.HWUPP = Hwi.create(6, "&upp_isr", hwi0Params);*/

var loggerSys0Params = new LoggerSys.Params();
loggerSys0Params.instance.name = "loggerSys0";
Program.global.loggerSys0 = LoggerSys.create(loggerSys0Params);

var loggerBuf0Params = new LoggerBuf.Params();
loggerBuf0Params.instance.name = "loggerBuf0";
Program.global.loggerBuf0 = LoggerBuf.create(loggerBuf0Params);
Error.common$.logger = Program.global.loggerBuf0;
LoggingSetup.loadTaskLogging = true;
1537.cfg_file.txt
var Defaults = xdc.useModule('xdc.runtime.Defaults');
var Diags = xdc.useModule('xdc.runtime.Diags');
var Error = xdc.useModule('xdc.runtime.Error');
var Log = xdc.useModule('xdc.runtime.Log');
var LoggerBuf = xdc.useModule('xdc.runtime.LoggerBuf');
var Main = xdc.useModule('xdc.runtime.Main');
var SysMin = xdc.useModule('xdc.runtime.SysMin');
var System = xdc.useModule('xdc.runtime.System');
var Text = xdc.useModule('xdc.runtime.Text');

var BIOS = xdc.useModule('ti.sysbios.BIOS');
var Hwi = xdc.useModule('ti.sysbios.hal.Hwi');
var LoggingSetup = xdc.useModule('ti.uia.sysbios.LoggingSetup');
var Clock = xdc.useModule('ti.sysbios.knl.Clock');
var Swi = xdc.useModule('ti.sysbios.knl.Swi');


var Hwi = xdc.useModule('ti.sysbios.family.c64p.Hwi'); // Added when flashing the code to the target
var LoggerSys = xdc.useModule('xdc.runtime.LoggerSys');
Hwi.resetVectorAddress = 0xc0000000;					 // Adedd when flashing the code. It's the place in 
														 // memory where appication will start off

/*
 * Uncomment this line to globally disable Asserts.
 * All modules inherit the default from the 'Defaults' module.  You
 * can override these defaults on a per-module basis using Module.common$.
 * Disabling Asserts will save code space and improve runtime performance.
Defaults.common$.diags_ASSERT = Diags.ALWAYS_OFF;
 */

/*
 * Uncomment this line to keep module names from being loaded on the target.
 * The module name strings are placed in the .const section. Setting this
 * parameter to false will save space in the .const section.  Error and
 * Assert messages will contain an "unknown module" prefix instead
 * of the actual module name.
 */
Defaults.common$.namedModule = false;

/*
 * Minimize exit handler array in System.  The System module includes
 * an array of functions that are registered with System_atexit() to be
 * called by System_exit().
 */
System.maxAtexitHandlers = 4;

/*
 * Uncomment this line to disable the Error print function.
 * We lose error information when this is disabled since the errors are
 * not printed.  Disabling the raiseHook will save some code space if
 * your app is not using System_printf() since the Error_print() function
 * calls System_printf().
Error.raiseHook = null;
 */

/*
 * Uncomment this line to keep Error, Assert, and Log strings from being
 * loaded on the target.  These strings are placed in the .const section.
 * Setting this parameter to false will save space in the .const section.
 * Error, Assert and Log message will print raw ids and args instead of
 * a formatted message.
 */
Text.isLoaded = false;

/*
 * Uncomment this line to disable the output of characters by SysMin
 * when the program exits.  SysMin writes characters to a circular buffer.
 * This buffer can be viewed using the SysMin Output view in ROV.
 */
SysMin.flushAtExit = false;

/*
 * The BIOS module will create the default heap for the system.
 * Specify the size of this default heap.
 */
//BIOS.heapSize = 4096;
BIOS.heapSize = 8192;
/* System stack size (used by ISRs and Swis) */
//Program.stack = 0x400;
Program.stack = 8192;


/* Circular buffer size for System_printf() */
SysMin.bufSize = 128;

/*
 * Create and install logger for the whole system
 */
var loggerBufParams = new LoggerBuf.Params();
//loggerBufParams.numEntries = 4;
//var logger0 = LoggerBuf.create(loggerBufParams);
//Defaults.common$.logger = logger0;
//Main.common$.diags_INFO = Diags.ALWAYS_ON;

System.SupportProxy = SysMin;

/*
 * Build a custom BIOS library.  The custom library will be smaller than the
 * pre-built "instrumented" (default) and "non-instrumented" libraries.
 *
 * The BIOS.logsEnabled parameter specifies whether the Logging is enabled
 * within BIOS for this custom build.  These logs are used by the RTA and
 * UIA analysis tools.
 *
 * The BIOS.assertsEnabled parameter specifies whether BIOS code will
 * include Assert() checks.  Setting this parameter to 'false' will generate
 * smaller and faster code, but having asserts enabled is recommended for
 * early development as the Assert() checks will catch lots of programming
 * errors (invalid parameters, etc.)
 */
BIOS.libType = BIOS.LibType_Custom;
//BIOS.logsEnabled = true;
BIOS.assertsEnabled = true;

LoggingSetup.enableTaskProfiler = true;

/*var clock0Params = new Clock.Params();
clock0Params.instance.name = "clock0";
clock0Params.period = 5000;
clock0Params.startFlag = true;
Program.global.clock0 = Clock.create("&WD_Kick", 5000, clock0Params);*/

//HWI Interrupt for uPP
/*var hwi0Params = new Hwi.Params();
hwi0Params.instance.name = "HWUPP";
hwi0Params.eventId = 94;
hwi0Params.priority = 2;
hwi0Params.enableInt = true;
Program.global.HWUPP = Hwi.create(6, "&upp_isr", hwi0Params);*/

var loggerSys0Params = new LoggerSys.Params();
loggerSys0Params.instance.name = "loggerSys0";
Program.global.loggerSys0 = LoggerSys.create(loggerSys0Params);

var loggerBuf0Params = new LoggerBuf.Params();
loggerBuf0Params.instance.name = "loggerBuf0";
Program.global.loggerBuf0 = LoggerBuf.create(loggerBuf0Params);
Error.common$.logger = Program.global.loggerBuf0;
LoggingSetup.loadTaskLogging = true;
  

  • Moving the thread to TI-RTOS E2E forum section.

    BR
    Tsvetolin Shulev
  • Carlos,

    Since you are not actually starting and using the kernel in your application it might be best to move this thread to a different forum.  (Sorry, I can see this thread was moved to the TI-RTOS forum, but I can’t see where it originally came from.)

    But, I have a guess…. maybe the DDR timings are not being set properly when you boot from flash?  It may be that when you run in the debugger there is some DDR initialization code in your GEL file.  And this is missing when you run without the debugger.  Have you checked for proper DDR setup when booting from flash?

    But since you are just writing the values to the buffers it isn’t clear to me why this would affect the blinking of the LEDs.  Unless there is some stalling or faulting happening when accessing unconfigured DDR?  Still, I think it would be good to double check DDR setup…

    Regards,
    Scott

  • I am open to suggestions regarding best forums ,

    Anyway, I can try bringing the code for DDR from GEL to source code. But I have another program that has same GEL, similar .cfg file, as far as I know same project properties and same platform file with a vector much larger and that works when flashing. I simply can't figure out why that works and this one, much simpler, doesn't. I also find somewhat wrong that I have to bring code from GEL to code. It sounds as if something should be working better, or I simply don't know (or have the visibility to see) all the limitations as to why that is happening. If I have software that runs with the debugger (buffers are being filled in correct DDR memory addresses, leds are blinking etc), and I am not using any pins/peripherals in a strange way (simple two LEDs) why the GEL doesn't get ported properly to the .out that I convert to a bin to flash the part?.

    Going back to that other application running. The vector is 65536x2 in size of Uint16 type and flashes fine. It's rather puzzling. The GEL enters configures the DDR (as in the other), then runs and blinks LEDs and fills the vector of 131072 of Uint16 numbers. I convert this out to .bin, flash it with boot.ais and works as well when booting from flash. What am I doing in that one that works (on same processor and board) that the other doesn't want to do? using same gel, same platform, same board
  • Carlos,

    The GEL file is used only within the CCS debug environment, and there is no automatic porting of that code when creating an image to be flashed.  

    Typically there are differences in the boot sequence when the device is booting standalone versus in a debugger.  For example, the device might be halted immediately when the debugger is connected, which means the normal device boot sequence is halted.  And then a new program is loaded in the debugger, with an entry point that is not the typical boot entry point.   Among other things, the GEL file provides a way to do some CPU/device initialization that would be handled differently/automatically when booted from flash, or from an attached processor.

    My mention of DDR configuration is just a guess, and I’m wondering if with the default configuration some portions of DDR may be accessible, and it is only for programs that access other portions (or pages?) that there are issues with the default configuration.  This may not be the problem, but I think it is important to check that the DDR configuration is correct when booting from flash.

    Also, you might look at other initialization code in the GEL file to see if there is something there that is missing when the device is booted from flash.

    Since your app is not actually using the kernel I’m going to ask that this thread be moved to the device forum.  I think you will get better help from the experts there…

    Regards,
    Scott

  • Carlos,

    A colleague had a suggestion, to try running some DDR memory testing early in the boot process.  You can add this to your application configuration file:

    var Startup = xdc.useModule('xdc.runtime.Startup');
    Startup.resetFxn = "&memTest";

    And add  a memTest() function to your app to do some write and readback of DDR memory to verify expected results.  And maybe light an LED or toggle an I/O to indicate success/fail in the flash boot case.

    Note that “reset” functions like this will be before C runtime initialization, so they cannot use any C global variables (because they won’t be initialized yet, and any values written to them by the reset function will be overwritten later, on the way to main()).

    Maybe you can try this?

    Thanks,
    Scott

  • Yes I can try, thanks!, I will toggle slowly an LEDs after a memory write from DDR in this memTest() and see if it goes through fine when flashing.
    For some reason I am having a lot of problems with flashing, I even tried the TI-RTOS app that blinks an LED using a HWi and a Swi from the TI-RTOS workshop, It works when using JTAG but not flashing, whether I have DDR or not this time. I use the reset point of 0xc0000000 in .cfg file and a platform file using DDR for all memory spaces, it simply wont blink the LED on the OMAPL138_LCDK... very frustrating. I have done the process many times converting .out to bin, using the bootloader for arm with 0xc0000000 entry point converting boot.out to boot.ais, flashing via UART, reboting via Flash (with right dipswitch settings), nope, doesn't want to blink. I have another app, relative to these programs is way more complicated, uses same gel, similar .cfg, same platform and that one works, what that one has that these don't, I have no idea. In any case, I will try memTest(), and thank you
  • Okay, this is interesting (I have the feeling I am close to learn a lesson, hopefully).

    I did the memTest() first using JTAG debugger. Essentially within void memTest(void){ ... }

    I do this in memTest:

    1) locally declare/define a buffer of certain size (which it stores in DDR space 0xc00xxxxx)

    2) setup pins to toggle some LEDs (pinMux, gpiopowerON, gpioDirection)

    3) Turn an LED ON

    4) Fill buffer declared/defined above

    5) turn LED OFF

    and this happens before main() as expected. I download program with debugger and I can see and actually can put breakpoints in memTest Fxn and see it's doing it (turning LEDs, filling buffer), and after it is done it goes, *sometimes*, to main() after that.

    When I use a buffer of less than 8192 the buffer declared in memTest is allocated somewhere in 0xc002xxxx (0XC0023b90) and then everything is fine and I start at main() after that with the rest of the code inside main() which executes fine as I can see. When I put a buffer of more than 8192 it puts this buffer at 0xc001xxxx (0XC001bc58) but this seems to collide with other things in code and effectively the cpu crashes and I never go to main(). This somewhat replicates what I see when I flash, but this time when using the debugger.

    Sometimes when I put a larger than 8192 buffer it actually loops within memTest for ever never going to main, sometimes it just crashes and goes to exit abort section.

    I also tried a large buffer of size 131072 and it puts the beginning of this address at 0xBxxxxxx and loops what it seems forever within memTest ....or sometimes crashes. It seems I am putting this buffer in some place in memory I shouldn't when  size is more than something?. Again, I have another program that uses a buffer of size 131072 ans that runs fine in debugger and after flashing... but this last test seems to suggest something wrong with the memory allocation?

    I have attached a screen capture of CCS showing the locatin of the buffer variable when size is 16384:

  • Carlos,

    OK, thanks for the update.  

    The inconsistent results (sometimes getting stuck in memTest(), sometimes not getting to main()) still makes me suspect memory timings or placement are part of the problem.  I see in the output window the GEL status messages:

    DDR initialization is in progress….
    PLL1 init done for DDR: 150MHz
    Using DDR2 settings
    DDR2 init for 150MHz is done


    These are the steps regarding DDR setup that I was mentioning to be sure are done in the boot from Flash case.  Maybe this is included somehow in that more complex application build you mention?

    I know you are not staring the kernel.  I wonder if you made a simpler “straight C” program built with the compiler and linker that calls memTest(), if you’d see that working as expected?  If this simple test fails too then the problem is clearly not related to TI-RTOS, ruling out a lot, and it should be easier to narrow it further, to maybe an issue with Flash config or boot settings, etc.    I wonder if you can try that?

    Thanks,
    Scott

  • I started from the HelloWorld.c program provided in CCS when creating a new project and replaced that main.c for this main.c below:

    Essentially the program turns ON one led turns ON the other alternatively and then writes to two buffers each of size 16384 16-bit unsigned integers. This repeats for ever.

    #define UPP_BUFFER_SIZE 16384
    Uint16 uPPRxBufferI[UPP_BUFFER_SIZE];
    Uint16 uPPRxBufferQ[UPP_BUFFER_SIZE];

    void main(void) {
    hardware_init(); // init hardware
    Uint32 i=0;
    while (1) {
    LED_ON(4);
    delay(1E6);
    LED_ON(5);
    delay(1e6);
    for (i=0;i<(UPP_BUFFER_SIZE);i++){
    uPPRxBufferI[i]=i;
    uPPRxBufferQ[i]=i+1;
    }
    }
    }

    I changed the linker cmd file so all sections will be located on DDR2 and _c_int00 will be placed at 0xc0000000, the linker cmd file is this:
    MEMORY
    {
    DSPL2ROM o = 0x00700000 l = 0x00100000 /* 1MB L2 Internal ROM */
    DSPL2RAM o = 0x00800000 l = 0x00040000 /* 256kB L2 Internal RAM */
    DSPL1PRAM o = 0x00E00000 l = 0x00008000 /* 32kB L1 Internal Program RAM */
    DSPL1DRAM o = 0x00F00000 l = 0x00008000 /* 32kB L1 Internal Data RAM */
    SHDSPL2ROM o = 0x11700000 l = 0x00100000 /* 1MB L2 Shared Internal ROM */
    SHDSPL2RAM o = 0x11800000 l = 0x00040000 /* 256kB L2 Shared Internal RAM */
    SHDSPL1PRAM o = 0x11E00000 l = 0x00008000 /* 32kB L1 Shared Internal Program RAM */
    SHDSPL1DRAM o = 0x11F00000 l = 0x00008000 /* 32kB L1 Shared Internal Data RAM */
    EMIFACS0 o = 0x40000000 l = 0x20000000 /* 512MB SDRAM Data (CS0) */
    EMIFACS2 o = 0x60000000 l = 0x02000000 /* 32MB Async Data (CS2) */
    EMIFACS3 o = 0x62000000 l = 0x02000000 /* 32MB Async Data (CS3) */
    EMIFACS4 o = 0x64000000 l = 0x02000000 /* 32MB Async Data (CS4) */
    EMIFACS5 o = 0x66000000 l = 0x02000000 /* 32MB Async Data (CS5) */
    SHRAM o = 0x80000000 l = 0x00020000 /* 128kB Shared RAM */
    DDR2 o = 0xC0000000 l = 0x20000000 /* 512MB DDR2 Data */
    }

    SECTIONS
    {
    .text > DDR2
    .text:_c_int00 > 0xc0000000 //added
    .stack > DDR2
    .bss > DDR2
    .cio > DDR2
    .const > DDR2
    .data > DDR2
    .switch > DDR2
    .sysmem > DDR2
    .far > DDR2
    .args > DDR2
    .ppinfo > DDR2
    .ppdata > DDR2

    /* COFF sections */
    .pinit > DDR2
    .cinit > DDR2

    /* EABI sections */
    .binit > DDR2
    .init_array > DDR2
    .neardata > DDR2
    .fardata > DDR2
    .rodata > DDR2
    .c6xabi.exidx > DDR2
    .c6xabi.extab > DDR2
    }

    This puts _c_int00 in 0xc0000000 then puts uPPRxBufferI starting at 0xc0008080 and uPPRxBufferQ starting at 0xc0000080 (main in further down) , I load from debugger and it runs fine (blinking leds and buffers filled), I Flash the part and it works as well as observed by LEDs blinking, no problems and I am using a 16384 size vector, which is the one that doesn't work in the other program. This one that flashes use the same boot.ais I have been using all along, so it shouldn't be any timing as it is same board, same part, and in fact it is not even a custom board, it is the LCDK. This looks like a configuration issue, not a timing issue. I am using same boot.ais as my other program that is not running, I am not setting up DDR in any way in my source code, I am just relying on the boot.ais to do that at boot time. I generate the boot.ais and I rely on a given configuration file provided for the LCDK which I use in the AISGen app to create the boot.ais from boot.out (boot.out is the output of compilation with desired entry point = 0xc0000000).

    I am able to run it with certain programs, like the one just done. What is different for this other program I am not sure yet as it uses same boot.ais, same entry point, but it is setup using TI-RTOS via .cfg file. Even if I don't start the kernel It may be using some memory space I am not supposed to use....the program that works that uses the TI-RTOS must somehow be getting it right, I can;t figure out what configuration is different in that one. ... I could copy that project and start from there, but that is not going to likely get to the bottom of the problem I am having.

    -----

    I also created a project from scratch using the template of the tyi-rtos for c6000 -> Kernel examples -> Minimal example. It uses a taskFxn in which I put the led toggling and filling of large buffer. like so:

    #include <xdc/std.h>
    #include <xdc/runtime/System.h>
    #include <ti/sysbios/BIOS.h>
    #include <ti/sysbios/knl/Task.h>
    #include <stdio.h>
    #include <c6x.h>
    #include <ti/csl/soc_C6748.h>
    #include <ti/csl/cslr_ddr2_mddr.h>
    #include <ti/csl/cslr_gpio.h>
    #include <ti/csl/cslr_syscfg0_C6748.h>
    #include <ti/csl/cslr_syscfg1_C6748.h>
    #include <ti/csl/cslr_psc_C6748.h>
    #include <ti/csl/cslr_pllc_C6748.h>

    #define BUFFER_SIZE 16384

    Uint16 uPPRxBufferI[BUFFER_SIZE];

    Void taskFxn(UArg a0, UArg a1)
    {
        Uint32 i=0;
        while(1){
            LED_ON(4);
            delay(1E6);
            LED_ON(5);
            delay(1e6);
            for (i=0;i<BUFFER_SIZE;i++){
                uPPRxBufferI[i]=i;
            }
        }
    }


    /*
     *  ======== main ========
     */
    Int main()
    {
        hardware_init(); // init hardware uses CSL
        BIOS_start();    /* does not return */
        return(0);
    }

    it runs from flash as long as BUFFER_SIZE <16384. Say if BUFFER_SIZE is 32768 it doesn't (but it runs with debugger in any case). This is, again, using the LCDK... and using this extra line to the provided .cfg of the minimal application so app will start off from 0xc0000000:

    var Hwi = xdc.useModule('ti.sysbios.family.c64p.Hwi'); // Added when flashing the code to the target
    Hwi.resetVectorAddress = 0xc0000000;                     // Adedd when flashing the code. It's the place in
                                                             // memory where appication will start off

  • I double checked and the simple application not using TI-RTOS but based on an empty project configuration runs fine even when using two vectors of 131072 size. The source code is identical, but it flashes fine when running the simple one, and break when flashing the one with ti-rtos ....

  • I also checked the setting for the DDR in the GEL nd compared them for the ones used in the AISGen and they differ.

    GEL uses following:

    DRPYC1R : C4

    SDCR: 13C832

    SDCR2: 0

    SDT1MR1: 264A3209

    SDT1MR2:3C14C722

    SDRCR: C0000492

    The config file for AISGen uses this:

    DRPYC1R : C5

    SDCR: 134832

    SDCR2: SAME

    SDT1MR1: SAME

    SDT1MR2:SAME

    SDRCR: 00000492

    I created another boot.ais using same parameters as used by GEL above, but get the same result. Large vector fails to flash, small vector flashes

  • Hi Carlos,

    Sorry for the delay, I’m just getting back to this.  And thanks for the additional details.  

    This is all very puzzling.  

    The empty project you mention, is that the TI-RTOS empty project, or the compiler’s empty project (Project -> New CCS Project-> Empty Project (with main.c))?  

    I’m thinking back to the case where you’d run memTest() as a reset function (which gets invoked right after the program entry point and stack pointer initialization), and how that wasn’t working consistently.  The only thing ‘TI-RTOS’ about that test is the initial calling of the reset function, and memory placement.  I can’t see how that could fail, but running the test in main() with no TI-RTOS will run consistently.  

    I guess if your app has other reset functions (others may be configured by your app) that run before memTest(), then that could be causing a difference.

    Looking at your test, I see you’ve put everything in DDR2, and also that you are writing to the two arrays, but not checking to see if read backs after the writes show the expected values.  I’d originally been thinking of a test that runs from internal memory, but does a memory access/integrity check of DDR2, basically a “soak” test of continuous writes/reads of DDR2 locations.  And using the LED to indicate if values read back are correct, or if a failure is seen.  I wonder if you can tweak the test to do that?  And if it passes in empty, try again as a reset function?

    Also, if you can check in the debugger, stepping from the _c_int00 entry point to get to your memTest() reset function, to see if there are any other functions that get invoked earlier than memTest()?  Your project might be configured to “go main” automatically after loading the program.  You can disable this (so you can start at _c_int00) by Tools->Debugger Options->Program/Auto Run and Launch Options, and then uncheck “On a program load or restart” after the Run to symbol: main.

    Sorry I don’t have any better ideas at this point.  But if you can get these additional data points that will rule out a couple more things.  I will also ask around for other ideas…

    Regards,
    Scott

  • Hi,

    The empty project I used is one of the templates offered in CCS for TI-RTOS. This is get to by going:

    Project--> New CCS Project

    + Select LCDK6748 on the Target section

    + Select Advance Settings and expand where it reads TI-RTOS for C6000 (below SYS/BIOS)

    + Expand Kernel Examples, then I selected Minimal, which "This example has a fairly minimal .cfg which is set up for a static application where all objects are defined statically (via configuration tool and/or target structures).  Dynamic memory allocation has been disabled. The .cfg file creates a single task which has a couple of print statements and a Task_sleep() call."

    I use that one to simply write and read a buffer of Uint16 values and turn on and off two LEDs running on the TI LCDK OMAPL138 board. I used the C6748_LCDK.gel provided. I only change the .cfg by adding two lines to tell it  to start running from 0xc0000000. It runs under debugger regardless of the size of the buffer, but not always when I flash this program. When the buffer is 16384 large, the program flashes fine, when this buffer is 32768 it doesn't. I can see when it is running because I can see the LEDs flashing every time I read a value from the buffer. I am not sure I understand what you are suggesting to do with internal memory versus DDR2, can you help with a little more detail?. I want to run from DDR2, the program that I used usng a simple non ti-rtos does work..

    I think it would help if someone can replicate what I am trying to do. I am not using non-standard hardware, it is the TI eval board (the LCDK, which I think has two or three different names, but in general is the LCDK with the OMAP-L138 in it).

    Again, the main.c function is this:, I don't think there is anything extra ordinary in it, :

    /*
     *  ======== main.c ========
     */

    #include <xdc/std.h>
    #include <xdc/runtime/System.h>
    #include <ti/sysbios/BIOS.h>
    #include <ti/sysbios/knl/Task.h>

    #include <stdio.h>
    #include <c6x.h>
    #include <ti/csl/soc_C6748.h>
    #include <ti/csl/cslr_ddr2_mddr.h>
    #include <ti/csl/cslr_gpio.h>
    #include <ti/csl/cslr_syscfg0_C6748.h>
    #include <ti/csl/cslr_syscfg1_C6748.h>
    #include <ti/csl/cslr_psc_C6748.h>
    #include <ti/csl/cslr_pllc_C6748.h>

    #define BUFFER_SIZE 32768

    Uint16 uPPRxBufferI[BUFFER_SIZE]; //This is the buffer

    // Peripheral registers (CSL library)-----------------------------------------
    // Sys config registers overlay
    CSL_SyscfgRegsOvly sys0Regs = (CSL_SyscfgRegsOvly) (CSL_SYSCFG_0_REGS);
    //Psc register overlay
    CSL_PscRegsOvly psc1Regs = (CSL_PscRegsOvly) (CSL_PSC_1_REGS);
    //CSL_PscRegsOvly psc0Regs = (CSL_PscRegsOvly) (CSL_PSC_0_REGS);
    // Gpio register overlay
    CSL_GpioRegsOvly gpioRegs = (CSL_GpioRegsOvly) (CSL_GPIO_0_REGS);


    static void hardware_init(void);
    static void device_init(void);
    static void pinMUX(void);
    static void delay(Uint32 count);
    static void gpioPowerOn(void);
    static void gpioDirection(void);
    static void LED_ON(unsigned int);

    /*
     *  ======== taskFxn ========
     */
    Void taskFxn(UArg a0, UArg a1)
    {
        Uint32 i=0;
        while(1){
            for (i=0;i<BUFFER_SIZE;i++){
                uPPRxBufferI[i]=i;
            }
            for(i=0;i<BUFFER_SIZE;i++){
                if(uPPRxBufferI[i]==i){
                    LED_ON(4);
                    delay(5E6);
                    LED_ON(5);
                    delay(5e6);
                }
            }
        }
    }


    /*
     *  ======== main ========
     */
    Int main()
    {
        hardware_init(); // init hardware
        BIOS_start();    /* does not return */
        return(0);
    }


    void hardware_init(void) {
        device_init();
    }

    void device_init(void) {

        //PLL configuration ---------------------------------------------------
        //setupPll0(24); // will do 24 MHZ x (24+1) / 2 = 300 MHz SYSCLK1
        //---------------------------------------------------------------------

        //Pin Multiplexing setup ----------------------------------------------
        pinMUX();
        //---------------------------------------------------------------------

        // GPIO SETUP ---------------------------------------------
        // Enable the GPIO Module in the PSC
        gpioPowerOn();
        gpioDirection();

    }

    void pinMUX(void) {

        // Key to be written to enable the pin mux registers for write
        sys0Regs->KICK0R = 0x83E70B13;
        sys0Regs->KICK1R = 0x95A4F1E0;


        sys0Regs->PINMUX13 |= ((CSL_SYSCFG_PINMUX13_PINMUX13_15_12_GPIO6_12)\
                            << (CSL_SYSCFG_PINMUX13_PINMUX13_15_12_SHIFT))\
                            |((CSL_SYSCFG_PINMUX13_PINMUX13_11_8_GPIO6_13)\
                            <<(CSL_SYSCFG_PINMUX13_PINMUX13_11_8_SHIFT));//LEDs D4,D5
    }

    void delay(Uint32 count) {
        volatile Uint32 tempCount = 0;

        for (tempCount = 0; tempCount < count; tempCount++) {
            /* dummy loop to wait for some time  */
        }
    }

    void gpioPowerOn(void) {

        volatile Uint32 pscTimeoutCount = 10240u;
        Uint32 temp = 0;

    // power on GPIO module in PSC & enable GPIO module
        psc1Regs->MDCTL[CSL_PSC_GPIO] =
                ((psc1Regs->MDCTL[CSL_PSC_GPIO] & 0xFFFFFFE0)
                        | CSL_PSC_MDSTAT_STATE_ENABLE);

    // Kick start the Enable command
        temp = psc1Regs->PTCMD;
        temp = ((temp & CSL_PSC_PTCMD_GO0_MASK)
                | (CSL_PSC_PTCMD_GO0_SET << CSL_PSC_PTCMD_GO0_SHIFT));

        psc1Regs->PTCMD |= temp;

    // Delay enough time for power state transition to occur (status not checked, this is the defn of HOPE)
        while (((psc1Regs->PTSTAT & (CSL_PSC_PTSTAT_GOSTAT0_IN_TRANSITION)) != 0)
                && (pscTimeoutCount > 0)) {
            pscTimeoutCount--;
        }
    }

    void gpioDirection(void) {

        // LED D4=GPIO6-13| LED D5=GPIO6-12

        // Configure GPIO6_13 (GPIO6_13_PIN) as an output LED4
        CSL_FINS(gpioRegs->BANK[3].DIR, GPIO_DIR_DIR13, 0);

        // Configure GPIO6_12 (GPIO6_12_PIN) as an output LED5
        CSL_FINS(gpioRegs->BANK[3].DIR, GPIO_DIR_DIR12, 0);

    }

    /*
     * Turns ON/OFF LEDs
     */
    void LED_ON(unsigned int led) {
        switch (led) {
        case 0:
            CSL_FINS(gpioRegs->BANK[3].OUT_DATA, GPIO_OUT_DATA_OUT13, 0);    //LED4
            CSL_FINS(gpioRegs->BANK[3].OUT_DATA, GPIO_OUT_DATA_OUT12, 0);    //LED5
            break;
        case 4:
            CSL_FINS(gpioRegs->BANK[3].OUT_DATA, GPIO_OUT_DATA_OUT13, 1);    //LED4
            CSL_FINS(gpioRegs->BANK[3].OUT_DATA, GPIO_OUT_DATA_OUT12, 0);    //LED5
            break;
        case 5:
            CSL_FINS(gpioRegs->BANK[3].OUT_DATA, GPIO_OUT_DATA_OUT13, 0);    //LED4
            CSL_FINS(gpioRegs->BANK[3].OUT_DATA, GPIO_OUT_DATA_OUT12, 1);    //LED5
            break;
        default:
            break;
        }
    }


  • Hi Carlos,

    Sorry for the delay, I’ve been in/out of office and am just getting back to this now.  And thanks for the additional details, and for modifying your test app.

    Regarding running your application from DDR2… what I was getting at is if DDR2 timing is not quite right, to not try to be running code out of this same memory, but to run the test code from internal memory, and test the DDR2 memory accesses by writes/reads to make sure there isn’t any issue with DDR2.  Not as a long term solution, but only as a test, to make sure DDR2 is behaving OK.  If the memory is not configured right it might explain why sometimes your tests work and sometimes they don’t or crash.

    I think I can probably borrow an LCDK board from a coworker at my TI site, but I don’t have one that I can try to recreate this test right now.  

    In the code you posted the call to setupPLL0() is commented out.  Is this intentional, and more specifically are you configuring PLL1?

    Also, have you tried stepping the app in the debugger from the _c_int00 entry point to see if there are any reset functions being run?

    I just searched the TI forums for “problem boot flash C6748” and found many hits.  I see one from about 6 months ago that points to an issue with AISgen, which makes me wonder if you are hitting something similar: e2e.ti.com/.../466012 What version of AISgen are you using?

    Tomorrow morning I will check with the TI-RTOS forum moderator to see who in the device group I can discuss this with to get this problem resolved for you…

    Regards,
    Scott

  • Thanks Scott.

    Regarding AISgen, I am using AISgen for D800K008 Version 1.9.

    Regarding the setuppll0(24). I commented it out just to test, but doesn't have any effect. Essentially when running from debugger the gel file sets this, and if running from flash the boot.ais set it as well, so it doesn't really have any effect other than setting the pllt0 again within main. The problem is replicated in the same way as explained before whether this is commented out or not.

    Yes, I don't think there are any reset function from _c_int00.

    I think we can get to the bottom of this once you get a hold of an LCDK and put the code I sent you in it and starting from the Minimal template for TI-RTOS 6000...hopefully that will illuminate us. Unless I am using an old verison of AISgen ....

    Thanks
  • Hi Carlos,

    What about the setup for PLL1?  That is the one that is critical for DDR2.  Is PLL1 also setup exactly the same in the Flash boot case as in the GEL for CCS?

    Did you try actually stepping from _c_int00?  It is important to know for sure there aren’t any reset functions running that might be changing some settings.  There may or may not be something there depending upon your version of the software.

    What version of SYS/BIOS are you using?  Is this part of an SDK or something you installed specifically?

    And what is the exact name of your LCDK board and revision number?  You mentioned earlier that it has an OMAP-L138 in it.  Is there any code booting on the ARM side in the Flash boot case that could be interfering with your test?  

    Thanks,
    Scott

  • I'd moved this to the device forum to see if they have some ideas.