.ebss from lib placement

Hello

Is this thread not supported by TI people.

Reto

Hello Bernd

I have seen that this solution with adding the ebbs to the program ram was already done in

Flash28335_API_V210.lib - Flash_Erase() Question

But I missing there a final statement if thats ok. Is there an other way how the  -lFlash28335_API_V210.lib(.ebss) part can be placed to a fix data ram region.

Reto,

we will come back on that.

Regards, Bernd

Trying to force the bootloader to use specific addresses/memory is not the way to do this.  You want to use two seperate projects, one for your secondary bootloader, the other for your main app.  You restrict the secondary bootloader to flash sector A (or more if needed), and restrict the main app to the rest of the flash.  Both projects should be fully self-contained.

There are many posts about how to connect the two projects at runtime.  A recent such post is this one:

http://e2e.ti.com/support/microcontrollers/c2000/f/171/p/383198/1357443.aspx#1357443

Regards,

David

We have some reasons to do this on that way. Is there a solution to handle it?

In the past we had two projects but for qualification reasons it's much more comfortable to handle it in one project. We spend some bigger effort to include all in one project and from my understanding this should be the last point.

Do you you some ideas how it could work?

Thanks

Reto

There are some real issues with trying to update only a piece of a project (your main app), but leave the rest of the project alone (your secondary bootloader).  What will you do with the _c_int00 routine?  Will this be updated, or will this stay static in flash with the secondary bootloader?  What about the .cinit section.  If both your secondary bootloader and your main app have initialized global vars or static locals, you'll have major problems.  Also, how will the _c_int00 routine find your .cinit section?  How will it initialize global variables for your secondary bootloader if _c_int00 is part of the updated code piece?  (I suppose you can avoid using any initialized global vars in the secondary bootloader easy enough).

If you are adamant about keeping the two programs in a single project, you can differentiate down to the file level in the linker command file.  For example, suppose you want to link the .text section from the secondary bootloader file(s).  In the linker command, you form a new section containing these .text sections.  For example, let SB denote secondary bootloader, and MA main app:

SECTIONS
{
  .text_SB:      > Flash_A, PAGE=0
    {
      SB_file_1.obj{.text}
      SB_file_2.obj{.text}
       ...
      SB_file_n.obj{.text}

    }

  .text_MA:      > Flash_BCDEFGH, PAGE=0
    {
      MA_file_1.obj{.text}
      MA_file_2.obj{.text}
       ...
      MA_file_n.obj{.text}
    }
}

You can do this for any/all sections.  This will allow you to seperate the secondary bootloader and main app in the single project.  The issue of the _c_int00 routine and .cinit section still remains.  There are probably other issues as well.

Regards,

David

Hello David

We get also the impression that's difficult to realize. I would say we have done must points you wrote with one exception, that .ebss part of the flash lib is not fixed.

When it changes the address the bootloader is still working as expected but the main application has a problem because .cinit of the flash lib points to wrong addresses. 

Therefore I come back with my question how this RAM part can be fixed.

As I wrote including the ebss like below is that OK for TI?

   Flash28_API:
   {
        -lFlash28335_API_V210.lib(.ebss)
        -lFlash28335_API_V210.lib(.econst)
        -lFlash28335_API_V210.lib(.cinit)
        -lFlash28335_API_V210.lib(.text)


   }                   LOAD = FLASHAPI,
                       RUN = RAMFLASHAPI,
                       LOAD_START(_Flash28_API_LoadStart),
                       LOAD_END(_Flash28_API_LoadEnd),
                       RUN_START(_Flash28_API_RunStart),
                       PAGE = 0

Or is there another way to handle it.

Thanks for your support

Reto

Hello David

I guess we have found the solution in another post.

http://e2e.ti.com/support/microcontrollers/c2000/f/171/t/231337.aspx

There they had the same problems as we have right now and the solution looks like that..

SECTIONS
{
.....
  Flash_Var:
   {
         _lFlash28335_API_V210.lib(.ebss)
   }                     LOAD = RAML4,

                           PAGE = 1

...

}

hi.

i am using 28335.

i read your problem about 28335.

and i am in the same problem. so i am very  depressed because of booting.

i want to update main application not jtag but custom communication.

so we choose boot to flash. and second bootloader must update new application.

so please give me your 28335.cmd file.

if you do that. i will appreciate it

my e-mail is choiwonseok@lignex1.com

please.

please refer to the my attachment file

1731.attach.pptx