Application code won't start after "USB Stick Update" based Firmware Update of TM4C1294NCPDT

Hi Amit,

Thanks for putting in your valuable time in assisting me. I have straight forward copied the bootloader example provided in the example codes section of EK-TM4C1294XL known as USB Stick Update. As far as my understanding goes, this code is approx. 17KB in size & it will load the binary image provided in a USB Thumb Drive (as a file named FIRMWARE.BIN) in the MCU's FLASH memory location starting from 0x8000. Since my binary file (FIRMWARE.BIN) is of size 234KB, it will fit in the memory easily.

 What is AOO_START_ADDRESS? Did you mean APP_START_ADDRESS? If so, then the APP START ADDRESS is 0x8000 (as provided in the provided example code of USB Stick Update).

 Regarding shifting/moving of the vector table, there is a function that gets called "CallApplication(APP_START_ADDRESS);". In this function, I believe, the vector table is moved accordingly by the statement "HWREG(NVIC_VTABLE) = ui32StartAddr;". After the vector table is moved, a few assembly code is executed as shown below:

//
// Load the stack pointer from the application's vector table.
//
__asm(" ldr r1, [r0]\n"
" mov sp, r1\n");

//
// Load the initial PC from the application's vector table and branch to
// the application's entry point.
//
__asm(" ldr r0, [r0, #4]\n"
" bx r0\n");

I think this code segment will transfer control of the CPU to the APP_START_ADDRESS contents.

-

Thanks

-

Regards

Soumyajit

Hi Arthur,

   Thanks for helping me, at least now I know the real cause of the issue. I initially had a project (TI-RTOS based) which I was unable to load using the said bootloader. To test the situation from a much basic point of view, I created a sample LED blink program (Non RTOS based) for testing purpose.

   As you mentioned, I opened the XXX_ccs.cmd file & found the #define APP_BASE 0x00000000, so I modified it to 0x00008000 & the LED blink program loaded from the Thumb Drive & is running successfully.

   Thinking that the issue is resolved, I opened my TI-RTOS based project to make similar modification of the XXX_css.cmd file, but there is no #define APP_BASE defined at all!!! How can I instruct the compiler to put the APP codes starting at FLASH location 0x00008000 in a TI-RTOS based project?

   PLEASE HELP!!

In the meanwhile, I'll try to rip the bootloader code to start copying FIRMWARE.BIN file from its starting location (0x00000000) to MCU FLASH starting location (0x00008000). In my opinion, it should work!

-

Thanks

-

Regards

Soumyajit

Hi Arthur,

   A detailed study of the XXX_ccs.cmd of the NON RTOS project showed that the APP_BASE declaration basically changes the following (highlighted in yellow):

/* The starting address of the application.  Normally the interrupt vectors  */

/* must be located at the beginning of the application.                      */

#define APP_BASE 0x00008000

#define RAM_BASE 0x20000000

/* System memory map */

MEMORY

{

   /* Application stored in and executes from internal flash */

   FLASH (RX) : origin = APP_BASE, length = 0x00100000

   /* 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 + 512;

-

    So, I decided to make the changes in the TI-RTOS XXX_ccs.cmd file but making the changes there is causing errors as follows:

#10264 DEFAULT memory range overlaps existing memory range FLASH
#10264 DEFAULT memory range overlaps existing memory range SRAM

& warning:

Warning points to linker.cmd file
#10096-D specified address lies outside memory map

linker.cmd contains a section which is pointed out by the warning link (highlighted in yellow):

SECTIONS
{
.bootVecs: type = DSECT
.vecs: load > 0x20000000
.resetVecs: load > 0x0

xdc.meta: type = COPY
}

  The changed section of the XXX_ccs.cmd file (highlighted in yellow) follows:

MEMORY
{
FLASH (RX) : origin = 0x00008000, length = 0x00100000
SRAM (RWX) : origin = 0x20000000, length = 0x00040000
}

/* 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=rtsv7M4_T_le_eabi.lib */

/* Section allocation in memory */

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

.vtable : > 0x20000000
.data : > SRAM
.bss : > SRAM
.sysmem : > SRAM
.stack : > SRAM
}

__STACK_TOP = __stack + 512;

-

PLEASE HELP!!

-

Thanks

-

Regards

Soumyajit

Hi Arthur,

   Thanks for pointing out the details but inspite of adding the following lines

-

Program.sectMap[".resetVecs"] = new Program.SectionSpec();

Program.sectMap[".resetVecs"].loadAddress = 0x00008000;

m3Hwi.resetVectorAddress = 0x00008000;

-

to the .cfg file, the .map file shows the following:

-

MEMORY CONFIGURATION

        name            origin    length      used     unused   attr    fill

----------------------  --------  ---------  --------  --------  ----  --------

 FLASH                 00000000   00100000  0000ce30  000f31d0  R  X

 SRAM                  20000000   00040000  0000418d  0003be73  RW X

SEGMENT ALLOCATION MAP

run origin  load origin   length   init length attrs members

----------  ----------- ---------- ----------- ----- -------

00000000    00000000    0000ce38   0000ce38    r-x

 00000000    00000000    0000003c   0000003c    r-- .resetVecs

 0000003c    0000003c    0000bfaa   0000bfaa    r-x .text

 0000bfe8    0000bfe8    00000b4a   00000b4a    r-- .const

 0000cb38    0000cb38    00000300   00000300    r-- .cinit

20000000    20000000    00000360   00000000    rw-

 20000000    20000000    00000360   00000000    rw- .vecs

20000400    20000400    00003e30   00000000    rw-

 20000400    20000400    0000351d   00000000    rw- .bss

 20003920    20003920    00000610   00000000    rw- .data

 20003f30    20003f30    00000300   00000000    rw- .stack

SECTION ALLOCATION MAP

output                                  attributes/

section   page    origin      length       input sections

--------  ----  ----------  ----------   ----------------

.bootVecs

*          0    00000000    00000008     DSECT

                 00000000    00000008     boot.aem4f : boot.oem4f (.bootVecs)

.resetVecs

*          0    00000000    0000003c    

                 00000000    0000003c     fatsdusbcopy_pem4f.oem4f (.resetVecs)

xdc.meta   0    00000000    000000fe     COPY SECTION

                 00000000    000000fe     fatsdusbcopy_pem4f.oem4f (xdc.meta)

xdc.noload

*          0    00000000    00001574     COPY SECTION

                 00000000    00001574     fatsdusbcopy_pem4f.oem4f (xdc.noload)

.init_array

*          0    00000000    00000000     UNINITIALIZED

-

    Am I missing something somewhere?

-

Thanks

-

Regards

Soumyajit