TM4C1294NCPDT: programming custom board for first time(tm4c1294ncpdt)

May I note that - for (any) "First Time Deployed" NEW BOARD -  "Bringing it up"  via  "JTAG/SWD" -  proves,  "SO VERY MUCH PREFERRED!"

KISS dictates:  "Simple, Limited, Focused"  FIRST STEPS.     Any bootloader - by definition - proves MASSIVELY in Violation!      Note that for (any) "New Board" - issues could be "Anywhere!"    Thus the value of the tightly focused, measured, KISS-dictated approach!

It is hoped that the (Normal/Customary)  "Provisioning of JTAG/SWD" - was included on poster's (custom) board.   (as that ALWAYS proves wise/SAVING)

As always - use of the smallest/simplest program (i.e. "blinky") - should be the first "Program Load" attempted.      (and that - via JTAG/SWD)    

Only after that  "JTAG/SWD Success" - should any more ambitious  "Programming Attempt"  - be launched...

respected sir,

Bob Crosby said:

Are you using a 25MHz crystal?

                Yes i am using 25 Mhz crystal.

Bob Crosby said:

Sometimes the bootloader gets confused if you do not have a resistor of 4.89K between RBIAS and GND.

There is 4.7k resistor between Rbais and GND which gives value of 4.529 K on DMM.

Another question is can i boot load without using external crystal at all (using internal oscillator to reduce probability of error)??   If yes, what are the changes i have to make in boot_demo1 and boot_serial example or  changes in other places??

regards,

digvijay

hi

Please Can anybody help me with this??

Regards,

Digvijay

digvijay khambe said:

Please Can anybody help me with this??

Was not "such help" - earlier offered up (28 April) - resulting in (only) silence?      That's NOT especially encouraging to others here - and (just may) explain your (on-going) plight...

"Your way" - and "your way only" - presents 'SO MANY 'UNKNOWNS' - adding great complications!        A far simpler (more CLASSICALLY EMPLOYED & PROVEN METHOD) remains, "Cast  Aside" - for unstated reason!     Perhaps ...  NOT the best means - to compel volunteer HELP!

Hi cb1_mobile

         I have already replied on 30 April and after that it went silent.

        And I started with the method I know. If there are better and simpler methods I am always open to it.  I did not focused on JTAG because right now I don't have debugger with me and I am not familiar with the process at all.

Regards,

Digvijay

digvijay khambe said:

I am not familiar with the process at all

My initial recommendation is to run the dbgjtag utility, but this requires JTAG. Are your soldering skills proficient to solder a header to the JTAG pins? The pins are tiny. I would not attempt this without a microscope.

Or one can also use EK-XL launch pad as a JTAG, remove 0R's 6,7,8,10,11,16,40, TP7 for shared GND. Then X11 (TXD/RXD) holes cross wire (X) into custom PCB UART (RXD/TXD). Also can use launch pads J6 JTAG header via ribbon cable or jumper wires into custom PCB JTAG header, not crossing wires. Do agree CB1 100%, Blinky can be rewritten to blink specific board LEDS via PIOSC or MOSC but it took awhile to figure out the wacky ass GPIO pin shifting only worked for one LED. Now my new (Blinky.bin) sports flip flopping LED'S. Will post it here if asked, let me know the LED's to blink..

This works even better than XDS100 since it creates CMD virtual link for LM Flash and CCS debug checks, virtual COM ports for debug listing etc..

Respected sir,

                    As suggested  above i tried debugging using JTAG and it worked fine. I was able to download boot_demo1 and uart_echo example. In uart_echo example i was able to transmit and receive data using terminal and uart0 module. So i can conclude that my power lines, crystal, uart0 section is working fine. But still i am not able to download the boot_demo1 example using UART and LM FLASH programmer. I have changed the pins(switch and led) used in boot_demo1 example according to my board and this is the only change. But still i am getting the same error as original post. So do i need to do some process/step before trying to download boot_demo1 example?? or is there something else missing??

regards,

digvijay

Bob Crosby said:

You might want to try this sequence on an EK-TM4C1294XL evaluation kit with unmodified examples.

To me - the above is an excellent suggestion.     I failed to detect the "MEANS" by which this poster is "Connecting" to the UART - on his "New/Custom board."    That's of (some) importance - is it not?

The vendor KIT employs the ICDI MCU to manage the Serial Transfer into UART - although not having that Kit - I'm on (not too steady) ground.    

This "Method of Connection" to the various MCU UARTS - to my mind - ALWAYS BEARS IMPROVED EXPLANATION!     (i.e. too often ... even SOME explanation...)

Poster should identify his: 

• Serial Signal Source
• the signal levels employed (the MCU's UART is restricted to CMOS/TTL signal levels)
• and the fact that the Signal Source properly MATES - (signal level wise) - with his MCU's 'restricted' input signal levels.

Poster has (just mentioned) some success via JTAG - such would have been (more) helpful - arriving earlier.    Indeed it establishes (some) level of board operation - always GOOD!

/*
 * Copyright (c) 2016, Texas Instruments Incorporated
 * All rights reserved.
 *
 * Redistribution and use in source and binary forms, with or without
 * modification, are permitted provided that the following conditions
 * are met:
 *
 * *  Redistributions of source code must retain the above copyright
 *    notice, this list of conditions and the following disclaimer.
 *
 * *  Redistributions in binary form must reproduce the above copyright
 *    notice, this list of conditions and the following disclaimer in the
 *    documentation and/or other materials provided with the distribution.
 *
 * *  Neither the name of Texas Instruments Incorporated nor the names of
 *    its contributors may be used to endorse or promote products derived
 *    from this software without specific prior written permission.
 *
 * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
 * AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO,
 * THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
 * PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR
 * CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL,
 * EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO,
 * PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS;
 * OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY,
 * WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR
 * OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE,
 * EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
 */
/*
 *  ======== EK_TM4C1294XL.cmd ========
 *  Define the memory block start/length for the EK_TM4C1294XL M4
 */

--retain=g_pfnVectors

/* The following command line options are set as part of the CCS project.    */
/* If you are building using the command line, or for some reason want to    */
/* define them here, you can uncomment and modify these lines as needed.     */
/* If you are using CCS for building, it is probably better to make any such */
/* modifications in your CCS project and leave this file alone.              */
/*                                                                           */
/* --heap_size=0                                                             */
/* --stack_size=256                                                          */
/* --library=rtsv7M3_T_le_eabi.lib                                           */

/* The starting address of the application.  Normally the interrupt vectors  */
/* must be located at the beginning of the application.                      */
#define APP_BASE 0x00004000
#define RAM_BASE 0x20000000

/* System memory map */

MEMORY
{
    /* Application stored in and executes from internal flash */
    FLASH (RX) : origin = APP_BASE, length = 0x000fc000
    /* Application uses internal RAM for data */
    SRAM (RWX) : origin = 0x20000000, length = 0x00040000
}

/* Section allocation in memory */

SECTIONS
{
    .intvecs:   > APP_BASE
    .text   :   > FLASH
    .const  :   > FLASH
    .cinit  :   > FLASH
    .pinit  :   > FLASH
    .init_array : > FLASH

    .vtable :   > RAM_BASE
    .data   :   > SRAM
    .bss    :   > SRAM
    .sysmem :   > SRAM
    .stack  :   > SRAM
}

__STACK_TOP = __stack + 1024;

/*
 * Copyright (c) 2015-2016, Texas Instruments Incorporated
 * All rights reserved.
 *
 * Redistribution and use in source and binary forms, with or without
 * modification, are permitted provided that the following conditions
 * are met:
 *
 * *  Redistributions of source code must retain the above copyright
 *    notice, this list of conditions and the following disclaimer.
 *
 * *  Redistributions in binary form must reproduce the above copyright
 *    notice, this list of conditions and the following disclaimer in the
 *    documentation and/or other materials provided with the distribution.
 *
 * *  Neither the name of Texas Instruments Incorporated nor the names of
 *    its contributors may be used to endorse or promote products derived
 *    from this software without specific prior written permission.
 *
 * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
 * AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO,
 * THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
 * PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR
 * CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL,
 * EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO,
 * PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS;
 * OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY,
 * WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR
 * OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE,
 * EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
 */



/* ================ Clock configuration ================ */
var Clock = xdc.useModule('ti.sysbios.knl.Clock');
/*
 * Default value is family dependent. For example, Linux systems often only
 * support a minimum period of 10000 us and multiples of 10000 us.
 * TI platforms have a default of 1000 us.
 */
Clock.tickPeriod = 1000;



/* ================ Defaults (module) configuration ================ */
var Defaults = xdc.useModule('xdc.runtime.Defaults');
/*
 * A flag to allow module names to be loaded on the target. Module name
 * strings are placed in the .const section for debugging purposes.
 *
 * Pick one:
 *  - true (default)
 *      Setting this parameter to true will include name strings in the .const
 *      section so that Errors and Asserts are easier to debug.
 *  - false
 *      Setting this parameter to false will reduce footprint in the .const
 *      section. As a result, Error and Assert messages will contain an
 *      "unknown module" prefix instead of the actual module name.
 */
Defaults.common$.namedModule = true;
//Defaults.common$.namedModule = false;



/* ================ Error configuration ================ */
var Error = xdc.useModule('xdc.runtime.Error');
/*
 * This function is called to handle all raised errors, but unlike
 * Error.raiseHook, this function is responsible for completely handling the
 * error with an appropriately initialized Error_Block.
 *
 * Pick one:
 *  - Error.policyDefault (default)
 *      Calls Error.raiseHook with an initialized Error_Block structure and logs
 *      the error using the module's logger.
 *  - Error.policySpin
 *      Simple alternative that traps on a while(1) loop for minimized target
 *      footprint.
 *      Using Error.policySpin, the Error.raiseHook will NOT called.
 */
Error.policyFxn = Error.policyDefault;
//Error.policyFxn = Error.policySpin;

/*
 * If Error.policyFxn is set to Error.policyDefault, this function is called
 * whenever an error is raised by the Error module.
 *
 * Pick one:
 *  - Error.print (default)
 *      Errors are formatted and output via System_printf() for easier
 *      debugging.
 *  - null
 *      Errors are not formatted or logged. This option reduces code footprint.
 *  - non-null function
 *      Errors invoke custom user function. See the Error module documentation
 *      for more details.
 */
Error.raiseHook = Error.print;
//Error.raiseHook = null;
//Error.raiseHook = "&myErrorFxn";

/*
 * If Error.policyFxn is set to Error.policyDefault, this option applies to the
 * maximum number of times the Error.raiseHook function can be recursively
 * invoked. This option limits the possibility of an infinite recursion that
 * could lead to a stack overflow.
 * The default value is 16.
 */
Error.maxDepth = 2;



/* ================ Hwi configuration ================ */
var halHwi = xdc.useModule('ti.sysbios.hal.Hwi');
var m3Hwi = xdc.useModule('ti.sysbios.family.arm.m3.Hwi');
/*
 * Checks for Hwi (system) stack overruns while in the Idle loop.
 *
 * Pick one:
 *  - true (default)
 *      Checks the top word for system stack overflows during the idle loop and
 *      raises an Error if one is detected.
 *  - false
 *      Disabling the runtime check improves runtime performance and yields a
 *      reduced flash footprint.
 */
halHwi.checkStackFlag = true;
//halHwi.checkStackFlag = false;

/*
 * The following options alter the system's behavior when a hardware exception
 * is detected.
 *
 * Pick one:
 *  - Hwi.enableException = true
 *      This option causes the default m3Hwi.excHandlerFunc function to fully
 *      decode an exception and dump the registers to the system console.
 *      This option raises errors in the Error module and displays the
 *      exception in ROV.
 *  - Hwi.enableException = false
 *      This option reduces code footprint by not decoding or printing the
 *      exception to the system console.
 *      It however still raises errors in the Error module and displays the
 *      exception in ROV.
 *  - Hwi.excHandlerFunc = null
 *      This is the most aggressive option for code footprint savings; but it
 *      can difficult to debug exceptions. It reduces flash footprint by
 *      plugging in a default while(1) trap when exception occur. This option
 *      does not raise an error with the Error module.
 */
m3Hwi.enableException = true;
//m3Hwi.enableException = false;
//m3Hwi.excHandlerFunc = null;

/*
 * Enable hardware exception generation when dividing by zero.
 *
 * Pick one:
 *  - 0 (default)
 *      Disables hardware exceptions when dividing by zero
 *  - 1
 *      Enables hardware exceptions when dividing by zero
 */
m3Hwi.nvicCCR.DIV_0_TRP = 0;
//m3Hwi.nvicCCR.DIV_0_TRP = 1;

/*
 * Enable hardware exception generation for invalid data alignment.
 *
 * Pick one:
 *  - 0 (default)
 *      Disables hardware exceptions for data alignment
 *  - 1
 *      Enables hardware exceptions for data alignment
 */
m3Hwi.nvicCCR.UNALIGN_TRP = 0;
//m3Hwi.nvicCCR.UNALIGN_TRP = 1;



/* ================ Idle configuration ================ */
var Idle = xdc.useModule('ti.sysbios.knl.Idle');
/*
 * The Idle module is used to specify a list of functions to be called when no
 * other tasks are running in the system.
 *
 * Functions added here will be run continuously within the idle task.
 *
 * Function signature:
 *     Void func(Void);
 */
//Idle.addFunc("&myIdleFunc");



/* ================ Kernel (SYS/BIOS) configuration ================ */
var BIOS = xdc.useModule('ti.sysbios.BIOS');
/*
 * Enable asserts in the BIOS library.
 *
 * Pick one:
 *  - true (default)
 *      Enables asserts for debugging purposes.
 *  - false
 *      Disables asserts for a reduced code footprint and better performance.
 */
//BIOS.assertsEnabled = true;
BIOS.assertsEnabled = false;

/*
 * Specify default heap size for BIOS.
 */
BIOS.heapSize = 1024;

/*
 * A flag to determine if xdc.runtime sources are to be included in a custom
 * built BIOS library.
 *
 * Pick one:
 *  - false (default)
 *      The pre-built xdc.runtime library is provided by the respective target
 *      used to build the application.
 *  - true
 *      xdc.runtime library sources are to be included in the custom BIOS
 *      library. This option yields the most efficient library in both code
 *      footprint and runtime performance.
 */
BIOS.includeXdcRuntime = false;
//BIOS.includeXdcRuntime = true;

/*
 * The SYS/BIOS runtime is provided in the form of a library that is linked
 * with the application. Several forms of this library are provided with the
 * SYS/BIOS product.
 *
 * Pick one:
 *   - BIOS.LibType_Custom
 *      Custom built library that is highly optimized for code footprint and
 *      runtime performance.
 *   - BIOS.LibType_Debug
 *      Custom built library that is non-optimized that can be used to
 *      single-step through APIs with a debugger.
 *
 */
BIOS.libType = BIOS.LibType_Custom;
//BIOS.libType = BIOS.LibType_Debug;

/*
 * Runtime instance creation enable flag.
 *
 * Pick one:
 *   - true (default)
 *      Allows Mod_create() and Mod_delete() to be called at runtime which
 *      requires a default heap for dynamic memory allocation.
 *   - false
 *      Reduces code footprint by disallowing Mod_create() and Mod_delete() to
 *      be called at runtime. Object instances are constructed via
 *      Mod_construct() and destructed via Mod_destruct().
 */
BIOS.runtimeCreatesEnabled = true;
//BIOS.runtimeCreatesEnabled = false;

/*
 * Enable logs in the BIOS library.
 *
 * Pick one:
 *  - true (default)
 *      Enables logs for debugging purposes.
 *  - false
 *      Disables logging for reduced code footprint and improved runtime
 *      performance.
 */
//BIOS.logsEnabled = true;
BIOS.logsEnabled = false;



/* ================ Memory configuration ================ */
var Memory = xdc.useModule('xdc.runtime.Memory');
/*
 * The Memory module itself simply provides a common interface for any
 * variety of system and application specific memory management policies
 * implemented by the IHeap modules(Ex. HeapMem, HeapBuf).
 */



/* ================ Program configuration ================ */
/*
 *  Program.stack is ignored with IAR. Use the project options in
 *  IAR Embedded Workbench to alter the system stack size.
 */
if (!Program.build.target.$name.match(/iar/)) {
    /*
     *  Reducing the system stack size (used by ISRs and Swis) to reduce
     *  RAM usage.
     */
    Program.stack = 768;
}



/*
 * Enable Semihosting for GNU targets to print to CCS console
 */
if (Program.build.target.$name.match(/gnu/)) {
    var SemiHost = xdc.useModule('ti.sysbios.rts.gnu.SemiHostSupport');
}
/* ================ Semaphore configuration ================ */
var Semaphore = xdc.useModule('ti.sysbios.knl.Semaphore');
/*
 * Enables global support for Task priority pend queuing.
 *
 * Pick one:
 *  - true (default)
 *      This allows pending tasks to be serviced based on their task priority.
 *  - false
 *      Pending tasks are services based on first in, first out basis.
 *
 *  When using BIOS in ROM:
 *      This option must be set to false.
 */
//Semaphore.supportsPriority = true;
Semaphore.supportsPriority = false;

/*
 * Allows for the implicit posting of events through the semaphore,
 * disable for additional code saving.
 *
 * Pick one:
 *  - true
 *      This allows the Semaphore module to post semaphores and events
 *      simultaneously.
 *  - false (default)
 *      Events must be explicitly posted to unblock tasks.
 *
 */
//Semaphore.supportsEvents = true;
Semaphore.supportsEvents = false;



/* ================ Swi configuration ================ */
var Swi = xdc.useModule('ti.sysbios.knl.Swi');
/*
 * A software interrupt is an object that encapsulates a function to be
 * executed and a priority. Software interrupts are prioritized, preempt tasks
 * and are preempted by hardware interrupt service routines.
 *
 * This module is included to allow Swi's in a users' application.
 */



/* ================ System configuration ================ */
var System = xdc.useModule('xdc.runtime.System');
/*
 * The Abort handler is called when the system exits abnormally.
 *
 * Pick one:
 *  - System.abortStd (default)
 *      Call the ANSI C Standard 'abort()' to terminate the application.
 *  - System.abortSpin
 *      A lightweight abort function that loops indefinitely in a while(1) trap
 *      function.
 *  - A custom abort handler
 *      A user-defined function. See the System module documentation for
 *      details.
 */
System.abortFxn = System.abortStd;
//System.abortFxn = System.abortSpin;
//System.abortFxn = "&myAbortSystem";

/*
 * The Exit handler is called when the system exits normally.
 *
 * Pick one:
 *  - System.exitStd (default)
 *      Call the ANSI C Standard 'exit()' to terminate the application.
 *  - System.exitSpin
 *      A lightweight exit function that loops indefinitely in a while(1) trap
 *      function.
 *  - A custom exit function
 *      A user-defined function. See the System module documentation for
 *      details.
 */
System.exitFxn = System.exitStd;
//System.exitFxn = System.exitSpin;
//System.exitFxn = "&myExitSystem";

/*
 * Minimize exit handler array in the System module. The System module includes
 * an array of functions that are registered with System_atexit() which is
 * called by System_exit(). The default value is 8.
 */
System.maxAtexitHandlers = 2;

/*
 * The System.SupportProxy defines a low-level implementation of System
 * functions such as System_printf(), System_flush(), etc.
 *
 * Pick one pair:
 *  - SysMin
 *      This module maintains an internal configurable circular buffer that
 *      stores the output until System_flush() is called.
 *      The size of the circular buffer is set via SysMin.bufSize.
 *  - SysCallback
 *      SysCallback allows for user-defined implementations for System APIs.
 *      The SysCallback support proxy has a smaller code footprint and can be
 *      used to supply custom System_printf services.
 *      The default SysCallback functions point to stub functions. See the
 *      SysCallback module's documentation.
 */
var SysMin = xdc.useModule('xdc.runtime.SysMin');
SysMin.bufSize = 128;
System.SupportProxy = SysMin;
//var SysCallback = xdc.useModule('xdc.runtime.SysCallback');
//System.SupportProxy = SysCallback;
//SysCallback.abortFxn = "&myUserAbort";
//SysCallback.exitFxn  = "&myUserExit";
//SysCallback.flushFxn = "&myUserFlush";
//SysCallback.putchFxn = "&myUserPutch";
//SysCallback.readyFxn = "&myUserReady";




/* ================ Task configuration ================ */
var Task = xdc.useModule('ti.sysbios.knl.Task');
/*
 * Check task stacks for overflow conditions.
 *
 * Pick one:
 *  - true (default)
 *      Enables runtime checks for task stack overflow conditions during
 *      context switching ("from" and "to")
 *  - false
 *      Disables runtime checks for task stack overflow conditions.
 */
Task.checkStackFlag = true;
//Task.checkStackFlag = false;

/*
 * Set the default task stack size when creating tasks.
 *
 * The default is dependent on the device being used. Reducing the default stack
 * size yields greater memory savings.
 */
Task.defaultStackSize = 512;

/*
 * Enables the idle task.
 *
 * Pick one:
 *  - true (default)
 *      Creates a task with priority of 0 which calls idle hook functions. This
 *      option must be set to true to gain power savings provided by the Power
 *      module.
 *  - false
 *      No idle task is created. This option consumes less memory as no
 *      additional default task stack is needed.
 *      To gain power savings by the Power module without having the idle task,
 *      add Idle.run as the Task.allBlockedFunc.
 */
Task.enableIdleTask = true;
//Task.enableIdleTask = false;
//Task.allBlockedFunc = Idle.run;

/*
 * If Task.enableIdleTask is set to true, this option sets the idle task's
 * stack size.
 *
 * Reducing the idle stack size yields greater memory savings.
 */
Task.idleTaskStackSize = 512;

/*
 * Reduce the number of task priorities.
 * The default is 16.
 * Decreasing the number of task priorities yield memory savings.
 */
Task.numPriorities = 16;



/* ================ Text configuration ================ */
var Text = xdc.useModule('xdc.runtime.Text');
/*
 * These strings are placed in the .const section. Setting this parameter to
 * false will save space in the .const section. Error, Assert and Log messages
 * will print raw ids and args instead of a formatted message.
 *
 * Pick one:
 *  - true (default)
 *      This option loads test string into the .const for easier debugging.
 *  - false
 *      This option reduces the .const footprint.
 */
Text.isLoaded = true;
//Text.isLoaded = false;



/* ================ Types configuration ================ */
var Types = xdc.useModule('xdc.runtime.Types');
/*
 * This module defines basic constants and types used throughout the
 * xdc.runtime package.
 */



/* ================ TI-RTOS middleware configuration ================ */
var mwConfig = xdc.useModule('ti.mw.Config');
/*
 * Include TI-RTOS middleware libraries
 */



/* ================ TI-RTOS drivers' configuration ================ */
var driversConfig = xdc.useModule('ti.drivers.Config');
/*
 * Include TI-RTOS drivers
 *
 * Pick one:
 *  - driversConfig.LibType_NonInstrumented (default)
 *      Use TI-RTOS drivers library optimized for footprint and performance
 *      without asserts or logs.
 *  - driversConfig.LibType_Instrumented
 *      Use TI-RTOS drivers library for debugging with asserts and logs enabled.
 */
driversConfig.libType = driversConfig.LibType_NonInstrumented;
//driversConfig.libType = driversConfig.LibType_Instrumented;



/* ================ Application Specific Instances ================ */

/* Use UARTMon with TI and GCC toolchains only */
if (!Program.build.target.$name.match(/iar/)) {
    var UARTMon = xdc.useModule('ti.tirtos.utils.UARTMon');
    UARTMon.stackSize = 1024;
}

var m3Hwi = xdc.useModule('ti.sysbios.family.arm.m3.Hwi');
m3Hwi.resetVectorAddress = 0x00004000; /* App base */ 

/*
 * Copyright (c) 2015, Texas Instruments Incorporated
 * All rights reserved.
 *
 * Redistribution and use in source and binary forms, with or without
 * modification, are permitted provided that the following conditions
 * are met:
 *
 * *  Redistributions of source code must retain the above copyright
 *    notice, this list of conditions and the following disclaimer.
 *
 * *  Redistributions in binary form must reproduce the above copyright
 *    notice, this list of conditions and the following disclaimer in the
 *    documentation and/or other materials provided with the distribution.
 *
 * *  Neither the name of Texas Instruments Incorporated nor the names of
 *    its contributors may be used to endorse or promote products derived
 *    from this software without specific prior written permission.
 *
 * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
 * AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO,
 * THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
 * PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR
 * CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL,
 * EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO,
 * PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS;
 * OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY,
 * WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR
 * OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE,
 * EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
 */

/*
 *  ======== gpiointerrupt.c ========
 */

/* XDCtools Header files */
#include <xdc/std.h>
#include <xdc/runtime/System.h>

/* BIOS Header files */
#include <ti/sysbios/BIOS.h>
#include <ti/sysbios/knl/Task.h>

/* TI-RTOS Header files */
#include <ti/drivers/GPIO.h>

/* Example/Board Header files */
#include "Board.h"

#include <stdbool.h>
#include <stdint.h>
#include "inc/hw_types.h"
#include "inc/hw_memmap.h"
#include "inc/hw_nvic.h"
#include "inc/hw_sysctl.h"
#include "inc/hw_gpio.h"
#include "driverlib/interrupt.h"
#include "driverlib/flash.h"
#include "driverlib/uart.h"
#include "driverlib/gpio.h"
#include "driverlib/rom.h"
#include "driverlib/sysctl.h"
#include "driverlib/pin_map.h"
#include <ti/sysbios/knl/Semaphore.h>

/* variable to be read by GUI Composer */
int count = 0;

/*
 *  ======== gpioButtonFxn0 ========
 *  Callback function for the GPIO interrupt on Board_BUTTON0.
 */
void gpioButtonFxn0(unsigned int index)
{

    System_printf("\n entered interrupt count=%d\n",count);
    /* SysMin will only print to the console when you call flush or exit */
    System_flush();
    /* Clear the GPIO interrupt and toggle an LED */
//    GPIO_toggle(Board_LED0);
//
//    if (count++ == 100) {
//        count = 0;
//    }

    HWREG(NVIC_DIS0) = 0xffffffff;
    HWREG(NVIC_DIS1) = 0xffffffff;
    HWREG(NVIC_DIS2) = 0xffffffff;
    HWREG(NVIC_DIS3) = 0xffffffff;

    //
    // Return control to the boot loader.  This is a call to the SVC
    // handler in the boot loader.
    //
    (*((void (*)(void))(*(uint32_t *)0x2c)))();
}

/*
 *  ======== gpioButtonFxn1 ========
 *  Callback function for the GPIO interrupt on Board_BUTTON1.
 *  This may not be used for all boards.
 */
//void gpioButtonFxn1(unsigned int index)
//{
//    /* Clear the GPIO interrupt and toggle an LED */
//    GPIO_toggle(Board_LED1);
//
//    if (count++ == 100) {
//        count = 0;
//    }
//}

/*
 *  ======== main ========
 */
int main(void)
{
    /* Call board init functions */
    Board_initGeneral();
    Board_initGPIO();
    Board_initUART();
    //
    // Configure the UART for 115200, n, 8, 1
    //
    UARTConfigSetExpClk(UART0_BASE, 120000000, 115200,
                            (UART_CONFIG_PAR_NONE | UART_CONFIG_STOP_ONE |
                             UART_CONFIG_WLEN_8));

    //
    // Enable the UART operation.
    //
    UARTEnable(UART0_BASE);

    /* Turn on user LED */
    GPIO_write(Board_LED0, Board_LED_ON);

    System_printf("Starting the GPIO Interrupt example\nSystem provider is set"
                  " to SysMin. Halt the target to view any SysMin contents in"
                  " ROV.\n");
    /* SysMin will only print to the console when you call flush or exit */
    System_flush();

    /* install Button callback */
    GPIO_setCallback(Board_BUTTON0, gpioButtonFxn0);

    /* Enable interrupts */
    GPIO_enableInt(Board_BUTTON0);

    /*
     *  If more than one input pin is available for your device, interrupts
     *  will be enabled on Board_BUTTON1.
     */
//    if (Board_BUTTON0 != Board_BUTTON1) {
//        /* install Button callback */
//        GPIO_setCallback(Board_BUTTON1, gpioButtonFxn1);
//        GPIO_enableInt(Board_BUTTON1);
//    }

    /* Start BIOS */
    BIOS_start();

    return (0);
}

                As u suggested When i program boot_serial first then it works. But i still have some doubts .

1. Why i cant use boot_serial from ROM?? When product is in production stage jtag is not feasible option.

2. I tried to add boot loader to gpiointerrupt example. But i am getting folloing error

entered interrupt count=0

FSR = 0x0000

HFSR = 0x40000000

DFSR = 0x00000001

MMAR = 0xe000ed34

BFAR = 0xe000ed38

AFSR = 0x00000000

Terminating execution...

The related code have been attached.

Regards

digvijay

digvijay khambe said:

1. Why i cant use boot_serial from ROM?? When product is in production stage jtag is not feasible option

Nice thing is with JTAG you can bulk erase the flash and trouble shoot the ROM boot loaders failure. Please review the BOOTCFG register 52 in datasheet for the default POR behavior. The BOOTCFG text is located throughout several sections, use CTRL-F search.  

Noticed your LM Flash posted above was loading offset 0x4000, that is your application? The serial boot loader has to be loaded to offset 0x0, it then copies starting from 0x4000 (application) into SRAM and executes it from SRAM. That may be a draw back to execution speed if the application is using DMA, is very large or has several memory related functions.  

In regards to your second topic/question, adding the boot loader to a TI-RTOS app is only meaningful if you intend to upgrade the firmware sometime after the initial production programming. Is this truly your goal? If so, you can call the ROM boot loader functions from the RTOS or call a customized boot loader vector. ROM source code is available. You can do whatever you want with the application code! There are many options for upgrading with a bootloader added to an RTOS application (UART, USB, Ethenet, etc).

This deserves its own post (in my opinion). You may distract help from your original programming problem.

Peter Borenstein said:

You may distract help from your original programming problem.

Well said - friend Peter.   

That said - it is my belief - not confined to 'just this poster' - that too often the, "Premature Rush to the Boot-Loader" (so long before the Final Application is "Fully & Properly" Tested/Verified) - almost GUARANTEES that the Project will wind up ... abandoned!      As this struggling poster admits (he has been "STUCK at this"  SO LONG - w/ SO LITTLE Success) - the drive to continue - just HAS TO  be reduced!

May it be asked,  "Just how many MORE - FAILED ATTEMPTS w/the Bootloader - must land here ...  prior to "Calling the Slaughter Rule?     Should its (attempted) use - perhaps - be ordered "BACK" - w/in the MCU Development Process?     This "Bootload Push-Back" method  - at minimum - builds Client-User skill, experience & confidence - before encountering & engaging,  "THE Challenge!"

Has it not been very well established - that he/she,  "First to Market - Reaps (by far) the highest Profit Margin!"     And yet - the (barely justified)  "Drive to Bootload" -  DEVOURS:  "Time, Energy, Funds & Morale!"   (while exhausting the "Crack Helper Crüe" ... (as is that matters!))

The boot-loader is - most always - something  to be deployed AFTER the Application has been PROVEN - and (some) Market Potential  has been confirmed.

Minus that - just as poster Peter has  well noted - the Premature Rush to 'Bootload'  tends to 'SABOTAGE - NOT ENHANCE'  far too many projects!     (which - should they arrive - land SO LATE - that  profit potential  - far too often ... has,  Left the Building!)

Respected sir,

Peter Borenstein said:

In regards to your second topic/question, adding the boot loader to a TI-RTOS app is only meaningful if you intend to upgrade the firmware sometime after the initial production programming. Is this truly your goal?

Yes , i need to upgrade the firmware after the initial production programming for example when product is in field. That is the reason i can not use jtag and i have to strictly stick to UART serial programming.

Peter Borenstein said:

If so, you can call the ROM boot loader functions from the RTOS or call a customized boot loader vector.

I tried calling boot loader by modifying gpiointerrupt  example. But it is terminating the execution by giving message as shown in above reply. I have attached modified code to the same reply.

Regards,

digvijay

Dear cb1_mobile,

cb1_mobile said:

so long before the Final Application is "Fully & Properly" Tested/Verified)

 Application has been completed in TI-RTOS and verified using launch pad. So only boot loading part is remaining

cb1_mobile said:

You may distract help from your original programming problem.

Boot loading the TI-RTOS application using UART serial at any time without JTAG is the main objective all along. So i think i am not deviating from my objective.

cb1_mobile said:

May it be asked,  "Just how many MORE - FAILED ATTEMPTS w/the Bootloader - must land here ...  prior to "Calling the Slaughter Rule?

I know that i am pushing hard. My 80 percent work is done so i dont want to give in now. And the information related to my problems is not in the documents. So i have to come to you guys for help.

Regards,

Digvijay

The bulk of my 05 May (7:09/19:09) post - was a general, "Statement of Fact" - only partially directed to you.    (yet still - I believe - applicable.)

By employing the Forum's Search Box (atop this page) you cannot help but note the LARGE NUMBER of Client-Posters - Struggling w/ these bootloaders.     That signals something - does it not?

If we assume that you have (some) commercial motivation - has this SIGNIFICANT DELAY - not INJURED your Profit-Seeking?      In my firm's case - should we be so delayed - 'Heads would ROLL!'     You are UNLIKELY to RECOVER these financial losses!    

There IS an alternative to the bootloader - that would see your shipping a 2nd device - w/your additions (likely corrections) to the client - crediting that client upon the original device's return.    This method is not at all uncommon - and - adds SECURITY to your design.     (Any bootloader provides (EASED) "back-door" entry to your code)

No one here wants to see you SO Struggle - it appears that (something) is not 'quite right' - w/SO MANY - just like you - Struggling in this effort...

Dear cb1_mobile

 So is there solution to it or not??  I really need it .

Regards,

Digvijay

digvijay khambe said:

While programming rtos application I am getting messages in console as shown in the above same reply. So how to add boot loader to TI-RTOS application??

You remain silent as to how custom PCB UART0 is being connected into PC, e.g, no posted schematic or answer to Bob's or CB1's very same question.

Q: The custom PCB UART0 connection has been (Verified) both TXD / RXD data into Windows console using a virtual COM port in echo mode?

Should custom PCB UART0 path into windows not be configured (full duplex) the ROM boot loader will likely fail! 

You are aware the ROMBL is embedded into the MCU at the factory so you don't need to flash the Serial BL?

We mostly need to verify why ROMBL struggles to find a COM path or halts/faults the MCU after POR. Please elaborate how the custom PCB is reacting to the UART's connection via CCS debug viewing registers as described below. 

One must configure CCS XML file to NOT load an application on launch into debug. Once in CCS debug, refresh continuous and peek the UART0 registers. Then establish a console connection to custom PCB UART0 via the virtual COM port inside CCS debug. Do you see any activity in the UART registers or console window?

***  LIKE  ***      Poster's (selective) responses - add to his delay & frustration...

Very nice detail - one (hopes) it will be appreciated.

digvijay khambe said:

So is there solution to it or not??  I really need it .

That's a COMMAND - is it not?      Not especially recognized as, 'DRAWING OTHERS' - to your AID!       Allowing your frustration to 'overflow' upon others (who devote time/effort - in YOUR Behalf) displays immaturity...    NONE HERE - by any means - caused YOUR ONGOING PLIGHT!

My recent post - argued that (it is likely) that Vendor must provide "EVEN FURTHER DETAIL" - as MANY (not just you) appear 'Over-Challenged'  - by the (multiple) demands - imposed by the bootloader(s).   

As to solution - 'IF and UNTIL you can 'Master the bootloader' - a PROVEN ALTERNATIVE - WAS PRESENTED!     (Despite your frustration's speaking - myself/others - DO HOPE that you (finally) succeed.)

Bob Crosby said:

It is possible to use the ROM based boot loader to reprogram a device. The application must disable all interrupts before calling the ROM based boot loader

How is that possible if the flash must be erased in order ROM boot loader to see 0xFFFF.FFFF at address 0x4?

Does the embedded ROM-BL have a similar flash erase function and it clears the EN bit of BOOTCFG?

If so that is great news for existing applications that in the past called firmware update function via the serial boot loader.

That is - without doubt - simply 'wonderful detail.'      That said - is this info well marked - even highlighted - anywhere else?     Clearly long-time poster/user BP101 - had 'No Such Knowledge!"

Surely, 'Not your Job' - yet does this not further, "MAKE THE CASE" for "EVEN FURTHER EXPLANATORY DETAIL" - SUCH AS  THAT YOU'VE JUST REVEALED?    

The fact that SO MANY - Stumble & Struggle w/ANY/ALL of the bootloaders - strongly points to the, "SERIOUS REQUIREMENT FOR ADDED DETAIL!"     (And that - beyond the often VITAL, "Bits & Pieces" (such as your post above) which will soon, "Rotate into Forum Oblivion!")     (and only rarely - if ever -  be  viewed again...)

I believe the blank check Bob is referring to is in bl_check.c which is called from bl_startup_ccs.s which appears to be in all boot loader examples:

uint32_t
CheckForceUpdate(void)
{
#ifdef CHECK_CRC
    uint32_t ui32Retcode;
#endif

#ifdef BL_CHECK_UPDATE_FN_HOOK
    //
    // If the update check function is hooked, call the application to determine
    // how to proceed.
    //
    return(BL_CHECK_UPDATE_FN_HOOK());
#else
    uint32_t *pui32App;

#ifdef ENABLE_UPDATE_CHECK
    g_ui32Forced = 0;
#endif

    //
    // See if the first location is 0xfffffffff or something that does not
    // look like a stack pointer, or if the second location is 0xffffffff or
    // something that does not look like a reset vector.
    //
    pui32App = (uint32_t *)APP_START_ADDRESS;
    if((pui32App[0] == 0xffffffff) ||
       ((pui32App[0] & 0xfff00000) != 0x20000000) ||
       (pui32App[1] == 0xffffffff) ||
       ((pui32App[1] & 0xfff00001) != 0x00000001))
    {
        return(1);
    }

Bob,

Thank you - much appreciated.     As a (past) tech writer (one of several 'hats') at another semi 'giant' - I realize that the "documentation is (never) - REALLY DONE!"     Yet - as you and numerous (vendor & client-user) others MUST have noted - a "Far too high" percentage of  users - FAIL (and badly)  when they attempt to employ the  bootloader.     It is good to know  such HAS been NOTED - and has 'landed' upon (some) list...

To Peter - you don't really expect - each/every client-user - to resort to "Digging Thru" every single source file - to ONLY THEN (maybe) "DISCOVER" - vitally needed data.

I'm suggesting - instead - that  far clearer & further detailed, "Bootloader Specifc Instructions" be introduced.      

Such AVOIDS - the PAINFULLY OBSCURED method - which you (somehow) appear to suggest!     (Even though - and especially though - you note '(that) code - appears in all bootloader manifestations!')    Has it not  been MISSED - by  both outside posters - herein?    (thread author & BP101)    That  IS a 100%  MISS-RATE - is it not?     

Are you arguing instead - that, "NO Such Improved/Extended - Descriptive/Guiding - Superior Bootloader Effort be launched?"      Really?

I would not say source is a substitute for documentation. My intent is to be helpful in small amounts and expand my own understanding.

I share some gripes on documentation. In this case, bl_check.c is documented in section 9.11 of the TivaWare Boot Loader guide (SPMU301D). The shortcoming is knowing if the ROM_ API calls this function.

Note the words "I believe". Its a guess! TI would get immediate value with little effort by specifying the source code projects used to make the ROM functions. This would take less time than comprehensive documentation. It would be difficult to comb through as you say, but not impossible. There is merit to source.

As it stands, some questions are only possible to answer if a TI employee takes the time to answer. I do not think BP101's question could be answered given infinite time. Another example of a related impossible question is here: e2e.ti.com/.../301719

As you state in the thread, The "verified" answer appears to me to be just, "pencil verified."

Another gripe, the documentation is scattered. Answers come from source code, cdoc, pdfs, and the wiki. A diligent engineer has to comb through all these sources to reach the point of requesting help. This incentivizes poor integrity. Should I spend time looking for answers that may not exist, or should I be lazy and post a new thread?

To give credit to TI, many questions I see posted could be answered by opening up the docs/ folder of a TivaWare install. I have respect for the work done.

You are NOT alone in having respect for the work done.    However - even 'work done' - as daily proven here - can be improved!     (And in proportion to the volume of Failures - Bootloader surely warrants (further) attention...)

Bob Crosby said:

The application would configure UART0 and then call "ROM_UpdateUART()" which is declared in rom.h

So your saying ROMBL clears the BOOTCFG register EN bit inside the embedded function "ROM_UpdateUART()" and is a high level device class call in rom.h.

Similarly Piccolo makes use of pre-written library class calls to invoke embedded motorware functions in several different MCU's. The motorware InstaSpin functions for one and later ROM class calls to invoke FOC spin algorithms, more specifically without InstaSpin library calls. It was hard to first grasp not all F286x MCU had the embedded InstaSpin class calls but make use of class calls to FOC spin algorithms all F286x are said to include.   

Perhaps the ROM embedded device class calls might be key to creating a simple PDF or (rombl.c) for access to all the embedded functions. 

Thanks Bob for needed clarification! :) 

BP101 said:

So your saying ROMBL clears the BOOTCFG register EN bit inside the embedded function "ROM_UpdateUART()"

No, what I am trying to say is that there are three ways to call the ROM bootloader.

1. If the first 8 bytes of the flash are blank (0xFF), the ROM bootloader runs and loops checking the different peripherals for connection to a device that establishes the boot loading protocol.

2. If the boot configuration non-volatile register is programmed to select a GPIO pin for boot loader activation and that GPIO pin is in the state selected when reset is released, then the ROM bootloader runs.

3. If the application makes a specific call to one of the bootloader update functions in ROM, such as "ROM_UpdateUART()". In this case the peripheral must be initialized by the application before calling the ROM_Updatexxxx function.

It is this third method that I was referring to in my earlier post.

Bob Crosby said:

1. If the first 8 bytes of the flash are blank (0xFF), the ROM bootloader runs and loops checking the different peripherals for connection to a device that establishes the boot loading protocol.

Oddly datasheet ROM boot loader BOOTCFG register text states it only checks location (0x4) for 0xFF.

Bob Crosby said:

2. If the boot configuration non-volatile register is programmed to select a GPIO pin for boot loader activation and that GPIO pin is in the state selected when reset is released, then the ROM bootloader runs.

It was not made very clear in datasheet Port H pins being set bypasses the blank check via EN pin of BOOTCFG register, good to know flash erase is not required. 

Bob Crosby said:

3. If the application makes a specific call to one of the bootloader update functions in ROM, such as "ROM_UpdateUART()". In this case the peripheral must be initialized by the application before calling the ROM_Updatexxxx function.

Tested this method yesterday calling ROM_UpdateEMAC(120000000). Typically we call serial boot loader via INT 0x02 to upload *.bin to the target from TFTP server. The Apps update call to ROM_update EMAC() turns off flashing LEDS, clears NVIC interrupts, disables watchdog then faulted the MCU while the client posted a message "Can not find the BootP server." EMAC0 was being used by the application telnet port that uploads (*.bin) from the GUI embedded TFTP server to the target. Not sure what is faulting the MCU but suspect the call semaphore for target Bootp server wrapper is bugged.

Also tested ROM_UpdateUART() (TM4C1294KCPDT) but use UART3 for virtual COM via TM4C123 ICDI and it too faulted the MCU. Even had LM Flash set up for the virtual COM port and posted similar message. May later test this again but find the Tivaware ROM  PDF is highly lacking any details relative to the embedded functions steps of execution.

As an after thought why MUC faulting ; Wonder if the ROM calls expect an application has (not) been previously flashed offset 0x0? Perhaps expects UART/EMAC vector tables exists above 0x0 at offset 0x0000.4000 and overwrites the current vector table configuration in the process of update?

That would be a deal breaker if ROM update expects (0x0000.4000) offset vector table. In my mind that defeats the idea of an ROM embedded flash utility, so we do not have to offset the application to 0x0000.4000 to make space for serial boot loafers vector table.

Respected sir,

BP101 said:

You remain silent as to how custom PCB UART0 is being connected into PC, e.g, no posted schematic or answer to Bob's or CB1's very same question.

         I am using  UART circuitry which used for general communication. I have tested it for transmit and receive operation. I have boot loaded the embedded firmware using UART0. So uart circuitry is not a problem. Problem is with TI-RTOS application. I am not able to call update (boot loader) function from TI-RTOS application.

Respected sir,

            Thanks for the simple explanation like this.

Bob Crosby said:

If the boot configuration non-volatile register is programmed to select a GPIO pin for boot loader activation and that GPIO pin is in the state selected when reset is released, then the ROM bootloader runs.

     As you suggested in the second option I tried to configure the GPIO pin for bootloader activation. but what I found is that i can select the GPIO pins from particular ports only. And port i have selected is not from those particular ports given in bootloader. I have kept some free GPIO pins but for my amazement all are useless. So I am unable to implement this option. So i am left with the third option only.

Bob Crosby said:

3. If the application makes a specific call to one of the bootloader update functions in ROM, such as "ROM_UpdateUART()". In this case the peripheral must be initialized by the application before calling the ROM_Updatexxxx function

                From all information gathered till now, i can conclude that to implement this third option i have to add some intelligence (like gpio interrupt) in my TI-RTOS application to call the function  "ROM_UpdateUART()".  After calling this function the controller will go into update mode (hopefully without any fault). Please correct me if i am wrong.

              Also BP101 has mentioned that by keeping 0x0000.4000 as offset leads to the fault condition.   So which offset should i  keep 0x0000.0000 or 0x0000.4000??

regards,

digvijay

The 0x4000 address is cited because the chip deletes flash in 16kB sectors. Section 8.2.3.10 of the datasheet says this. 0x4000 is the first 16kB boundary after 0. Most bootloaders will fit in 16kB so most applications with a flash based bootloader would start a the first boundary and the vector table is the first thing. Suppose your boot loader is 17kB; you would want to preserve the first 2 16kB sectors, so your app would start at address 0x8000.

The processor uses 4 byte words so you can't start at an odd address. You can start forward of a 16kB boundary, but you would be wasting memory.

This offset is used by flash based bootloaders as APP_START_ADDRESS (as seen in my cited code). It is not clear to me what the ROM bootloader uses as APP_START_ADDRESS hence BP101's question. I assume it expects the vector table at 0.

I am also open to corrections.

Edit: by vector table, I mean interrupt and reset vector table. The ROM functions are in a ROM based vector table.

Respected sir,

                Thanks for quick reply.  The flash boot loader has the boot loader placed at 0x0000.0000 and application at 0x0000.4000 but in ROM boot loader there is no boot loader placed at 0x0000.0000. So if we keep app at 0x0000.4000 the memory between 0x0000.0000 and 0x0000.4000 is empty. And i think this is the reason it gives fault.  I need to check it in lab. Anyway am i write about the steps to update TI-RTOS application except for the offset part??

Regards,

Digvijay

Hi Digvijay,

It was 3rd option I tested with ROM_EMAC(120000000) with application offset 0x0. The target after MCU fault then posted message "Can not find Bootp server". Please let us know if you too receive this same message or not. The other call ROM_UART() only supports UART0 typical RTOS device, simply call Board_initUART(); ,, recall the interrupt was part of the load loggers configuration. 

Also expected to use Option 2 - GPIO pin H3 since it is the last pin on port H regardless BOOTCFG register default of pin 7, it too is last pin. GPIO with 8 pins must have been for another MCU.

Respected sir,

                  I tried boot loading using third method but it did not work. In debugger control goes up to ROM_UpdateUART() but can not track after that. I think i am not able to access ROM functions. I have attached code, LM FLASH programmer configuration and error snap in zip file.

5504.bootloader.zip

Regards ,

Digvijay