• State
  • Locked Locked
  • Replies 4 replies
  • Subscribers 31 subscribers
  • Views 587 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

RM46L852: RM46L852 application bootup issue

Jeff Pu
Prodigy 100 points
Part Number: RM46L852

Hi,

I wonder if anyone saw the same issue with RM46 bootup. We are using TI tool chain along with HCG (04.03.00).  UART Bootloader is also used.

As application code size grows, we run into a point where application does not boot up any more. However, our code size about 256KB (far less than the flash size of 1.25MB). We also made sure that either data size or stack space are not an issue. 

Here are the two code segments.  It boots up fine with one,  but not the other.

Note that //dummyInt  in the following code segments is never equal to 0x1234.

////////////////////////////// following does not bootup /////////

void dummyFunction(int  dummyInt)

{

   if (dummyInt==0x1234) {   

function1();

function2();

  }

}

////////////////////////////// following bootup fine /////////

void dummyFunction(int  dummyInt)

{

   if (dummyInt=0x1234) {  

      //function1();

      //function2();

  }

}

As matter of fact,  dummyFunction() does not even get called on boot up.  

Thanks

Jeff

  • 0
    TI__Guru 72500 points
    Did you accidentally erase the UART boot loader at address 0? Are the application's vectors still at address 0x2000? You can check in the .map file that will be in debug directory.
  • 0 in reply to Bob Crosby
    Prodigy 100 points

    Thanks for your response. Bob,


    We modified boot loader a little bit, application vector is at 0x40000. Boot loader (start at 0x0) is not erased because it boots fine with the code segment in my first post.

    I included the map files of two builds (same link config,same code base, run on the same board), one boots up ok, the other does not boot up.

    ////////////////////////////// Did not boot up ////////////////////////////

    OUTPUT FILE NAME:   <badge_project.out>
    ENTRY POINT SYMBOL: "_c_int00"  address: 0007a240


    MEMORY CONFIGURATION

             name            origin    length      used     unused   attr    fill
    ----------------------  --------  ---------  --------  --------  ----  --------
      VECTORS               00040000   00000020  00000020  00000000     X
      FLASH0                00040020   000fffe0  0003fbe3  000c03fd  R  X
      STACKS                08000000   00002000  00000000  00002000  RW
      RAM                   08004000   0002c000  00011141  0001aebf  RW


    SEGMENT ALLOCATION MAP

    run origin  load origin   length   init length attrs members
    ----------  ----------- ---------- ----------- ----- -------
    00040000    00040000    0003fc08   0003fc08    r-x
      00040000    00040000    00000020   00000020    r-x .intvecs
      00040020    00040020    0003c75c   0003c75c    r-x .text
      0007c77c    0007c77c    00002ae7   00002ae7    r-- .const
      0007f268    0007f268    000009a0   000009a0    r-- .cinit
    08004000    08004000    00011148   00000000    rw-
      08004000    08004000    0000fb95   00000000    rw- .bss
      08013b98    08013b98    00000dac   00000000    rw- .data
      08014948    08014948    00000800   00000000    rw- .sysmem
    /////////////////////////////// boot up OK /////////////////

    OUTPUT FILE NAME:   <badge_project.out>
    ENTRY POINT SYMBOL: "_c_int00"  address: 0007a23c


    MEMORY CONFIGURATION

             name            origin    length      used     unused   attr    fill
    ----------------------  --------  ---------  --------  --------  ----  --------
      VECTORS               00040000   00000020  00000020  00000000     X
      FLASH0                00040020   000fffe0  0003fbdf  000c0401  R  X
      STACKS                08000000   00002000  00000000  00002000  RW
      RAM                   08004000   0002c000  00011141  0001aebf  RW


    SEGMENT ALLOCATION MAP

    run origin  load origin   length   init length attrs members
    ----------  ----------- ---------- ----------- ----- -------
    00040000    00040000    0003fc00   0003fc00    r-x
      00040000    00040000    00000020   00000020    r-x .intvecs
      00040020    00040020    0003c758   0003c758    r-x .text
      0007c778    0007c778    00002ae7   00002ae7    r-- .const
      0007f260    0007f260    000009a0   000009a0    r-- .cinit
    08004000    08004000    00011148   00000000    rw-
      08004000    08004000    0000fb95   00000000    rw- .bss
      08013b98    08013b98    00000dac   00000000    rw- .data
      08014948    08014948    00000800   00000000    rw- .sysmem

  • 0 in reply to Jeff Pu
    TI__Guru 61235 points

    Jeff,

    Does your app get programmed into the flash using the bootloader?  (check using CCS, inspect the flash in a memory window).

    If yes, can you debug/step through your app and find out where things go wrong?

    If no, can you debug/step through the bootloader and find out where things are going wrong?

    Regards,

    David

  • 0 in reply to David M. Alter
    Prodigy 100 points

    Hi, David,


    Thanks for help!

    Yes, we load application image thru boot loader.  This morning, we used CCS to debug it, found that the application works fine after CCS loads to the board. we played a little bit of compiler options and optimization, found there is no impact. Since then, we were thinking that the issue may lie in boot loader itself.

    From the boot loader source code, there is no issue regarding to the image size. However, we are dumping the flash partition where application image resides, and compare with image itself, found some inconsistency.
    That might be it.

    Thanks,

    Jeff