• Locked Locked
  • Replies 16 replies
  • Subscribers 55 subscribers
  • Views 3626 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

Link bootloader and application project with separate RTS-lib and copytables in CCS

MarcusW
Prodigy 20 points
Other Parts Discussed in Thread: UNIFLASH, MSP430F5253, MSP430F5529

Hi,


I'm struggling with a customized bootloader for an MSP430 FRAM controller. Although I have found several similar threads in this forum that helped me in solving the first issues, I have reached a point where I would appreciate further help from the community.

First, the big picture:


I have two separate CCS6.1 projects, one containing a "bootloader" and one containing "application" code.

At boot time, the bootloader checks application integrity and enters a special firmware update mode, if required. If the bootloader terminates, it branches to the application code. Bootloader and application should be absolutely independent. Therefore each code block should have its own rts-library (if needed).

My problem is now: How could I achive this in CCS?

Scenario 1 (simple, stupid, manual, ignoring interrupt handling for simplicity):

I think I could compile both projects individually, using two individual linker .cmd files for placing the code sections in a way that they are not overlapping.

Afterwards I could merge the output files (TI_TXT) in a text editor by hand.The reset vector should point to the bootloader _c_int00* function. Furthermore the _c_int00* function of the application project has to be placed in a location which is known by the bootloader. Therefore each project has its own runtime support library and its own autoinit functions. The projects are totally independent.

Obviously, manual merging of TI_TXT files is not very elegant, therefore I try to avoid this scenario.

Scenario 2 (unfortunately not working, yet):

I imported both project into one CCS workspace. The linker options of the bootloader project were modified to produce relocatable code (--relocatable). The application project links the compiled "bootloader.out" into the application project and places the bootloader code parts in a memory section defined in the application project's linker cmd file.

Now I have two problems which are bothering me:

- If I set the entry-point to the bootloader's _c_int00 function, the _c_int00 function of the application project will be omitted. At least I can't see it anymore in the application.map file. I need both _c_int00 functions to remain in the project.

- How do I get individual auto init functions (copy tables) for initialization of variables? At BOR-time the bootloader should initialize its own variables using its own autoinit function. After bootloader termination, the application _c_int00 should be called, causing the autoinit of the application being called.

-> Is it possible to tell the linker to merge these two projects in a way that they are totally independent?

-> Is there a better way to accieve my requirements using CCS?

I appreciate any help or suggestions which could help,

Regards,

Marcus

  • TI__Guru 56685 points

    Hello Marcus,

    Hopefully this information will help.  Manually merging the output files files is a solution then downloading the single out file to the device is a valid solution. I do admit it is not elegant and it seems like there should be a better way, while using CCS.  You can see me pointing tot his solution in the following E2E post:

    https://e2e.ti.com/support/development_tools/code_composer_studio/f/81/t/432845


    After speaking with the CCS team some, this is some alternatives tot his method. They are the following.

    you can load multiple .out files to a MSP430 target.

    -          Manually launch the target

    -          Go to menu Tools -> Debug Options ->MSP430 Debugger Options

    -          Select the option Erase and download necessary segments only (Differential Download)

    -          Go to menu Run ->Load ->Load Program. Repeat as many times as necessary.

     

    Obviously you want all your .out files to not have overlapping memory sections, otherwise they will be completely wiped out when loading the other .out file.

     

    Another overall approach would be to have a single project that holds both the BSL and the application. This would require:

    -          Create one or more custom memory sections on the linker CMD file that point to the BSL memory regions for code and data;

    -          Use the #pragma CODE_SECTION and #pragma DATA_SECTION before any C functions and global data. These pragmas place code/data in the        custom memory sections defined by the linker.

    -          Rename the main() function of the BSL project to something else, as it will clash with the application’s main() routine. Similar thing needs to be done on custom functions with the same name.

     

    Obviously this approach is very high level, but the single-project approach would have to involve at least these steps. You would be effectively manually placing functions into different parts of memory.

    Uniflash also has an option to load multiple .out files at the same time.

    Regards,

    JH

  • in reply to Jace H
    Expert 2690 points

    Hi,

    I tried the method of installing the bootloader followed by the application, and vice versa. In both cases, the second load wiped out the first one (i.e. if I load the bootloader, which lies in the address range of 0xa400-0xb3ff, and then load the application, which lies in 0x0xb400 and above, the application is correctly loaded, but the bootloader area is filled with 0xff). Is there a way to only erase the areas in memory that are needed?

  • in reply to Ed Ferrari SD
    Expert 2690 points
    By the way, I experienced this issue with both CCS 6.1.1 and CCS UniFlash. I tried the following:

    1) Erase main memory with UniFlash
    2) Choose the differential download erase option in CCS
    3) Load bootloader image
    4) Load application image

    I verified that the bootloader and application images have no overlapping sections, yet several sections of flash did not get programmed. If I combine the application and bootloader images into a single hex image, the download works fine. Is there a known issue with differential download with CCS 6.1.1 and CCS UniFlash?
  • in reply to Ed Ferrari SD
    TI__Guru 56685 points
    Edward,

    I have moved this thread to the CCS forum in order to get you better support.

    Regards,
    JH
  • in reply to Ed Ferrari SD
    TI__Guru**** 173310 points

    Edward Ferrari56 said:
    I tried the method of installing the bootloader followed by the application, and vice versa. In both cases, the second load wiped out the first one (i.e. if I load the bootloader, which lies in the address range of 0xa400-0xb3ff, and then load the application, which lies in 0x0xb400 and above, the application is correctly loaded, but the bootloader area is filled with 0xff).

    I could not reproduce this with CCS 6.1.1. I created two projects that had code in different regions of Flash (non-overlapping), set the Debug Properties of both projects to "Erase and download necessary segments only (Differential Download)" , clicked the Debug button to debug first project, and then loaded the second project using menu Run->Load->Load Program. The code of the first project still remained at its address as expected (was not erased) and the code of the second project got written to the expected addresses.

    Is your procedure or sequence of steps different from this?

  • in reply to AartiG
    Expert 2690 points
    I just tried your procedure and had the same results as I had before. After you loaded the 2nd image, did you click on the "refresh view" button in the Disassembly window? After I downloaded the 2nd image, the disassembly window still showed the image being present, but after I clicked on the refresh view button, it showed all F's in that area.
  • in reply to Ed Ferrari SD
    TI__Guru**** 173310 points

    Edward Ferrari56 said:
    After you loaded the 2nd image, did you click on the "refresh view" button in the Disassembly window?

    Yes. Even after clicking the Refresh view button it did not revert to FFFFs.

    I think the key is whether the correct Download option is selected for the debug launch configuration. Is the Differential Download option selected under Debug properties for the project that you are launching the debug session for?

    If you can describe the exact sequence of steps you are following and the settings for both of your projects, we might be able to identify what is different in your environment.

  • in reply to AartiG
    Expert 2690 points

    I'm performing the same steps as you, although I think I've narrowed down the issue. I definitely have differential download enabled, and I performed the following steps:

    1) Erase the main memory with CCS Uniflash

    2) Download the 1st image via Run->Debug

    I'm using a MSP430F5253, and the 1st image will occupy memory between 0xa400 and 0xb400. I noticed that with differential download selected, memory locations 0xa400 to 0xa7ff don't get written. If I perform the same steps with "Erase main memory only" option, it gets programmed correctly. I have memory dumps  of the 2 scenarios, but I don't see how to attach them. Is there some processor specific setting I may be missing?

  • in reply to Ed Ferrari SD
    TI__Guru**** 173310 points

    Edward Ferrari56 said:
    I have memory dumps  of the 2 scenarios, but I don't see how to attach them.

    To attach files: after clicking Reply to a post, click on "Use rich formatting". The reply box there should have options to attach images, files etc.

  • in reply to Ed Ferrari SD
    TI__Guru**** 173310 points

    Edward Ferrari56 said:
    I'm using a MSP430F5253, and the 1st image will occupy memory between 0xa400 and 0xb400. I noticed that with differential download selected, memory locations 0xa400 to 0xa7ff don't get written. If I perform the same steps with "Erase main memory only" option, it gets programmed correctly.

    I'm still a little confused about your sequence of steps.

    You say your first step is "Erase the main memory with CCS Uniflash". I'm not clear why you are using both Uniflash and CCS, as the same settings/behavior can be accomplished by both.  Since there is no "erase only" option for MSP430 (etiher in CCS or Uniflash), you can only set the erase options to apply during program download. In that case, which program are you downloading along with your erase main memory when using Uniflash? You may want to check if that download is somehow conflicting with the next download that is set for "Differential Download".

  • in reply to AartiG
    Expert 2690 points

    I'm assuming that when you want to use the differential download feature of CCS, you would use it for both images. So that's why I'm using CCS Uniflash to erase the memory first.

    It looks to me like CCS Uniflash can do an "erase only" by choosing Program->Erase. So I am not downloading anything with Uniflash. I'm using CCS Uniflash version 3.4.0.00002 if that matters.

  • in reply to Ed Ferrari SD
    TI__Guru**** 173310 points

    Edward Ferrari56 said:
    It looks to me like CCS Uniflash can do an "erase only" by choosing Program->Erase. So I am not downloading anything with Uniflash. I'm using CCS Uniflash version 3.4.0.00002 if that matters.

    You are correct, version 3.4 of Uniflash supports mass erase. I just tested the same procedure again, this time with using Uniflash to first perform the mass erase, and then loading both executables one after the other with CCS 6.1.1, and still cannot reproduce the issue.

    I am using a different device than you (MSP430F5529 Launchpad), and the code is being loaded to different memory addresses, however I don't think that should affect the behavior. So at this point, I am still unable to reproduce or explain the behavior you are seeing. As a last check, if you could zip up and attach the linker command files and .out files for your two projects, I could take a quick look to see if anything stands out. It might be a long shot, but at this point that is the only other thing I can think of.

  • in reply to AartiG
    Expert 2690 points

    Sure, I can do that. Can I send it to you privately? If you send me an e-mail at eferrari@awarepoint.com, I can reply with the zip file.

  • in reply to Jace H
    Prodigy 20 points

    Jace H said:

    Another overall approach would be to have a single project that holds both the BSL and the application. This would require:

    -          Create one or more custom memory sections on the linker CMD file that point to the BSL memory regions for code and data;

    -          Use the #pragma CODE_SECTION and #pragma DATA_SECTION before any C functions and global data. These pragmas place code/data in the        custom memory sections defined by the linker.

    -          Rename the main() function of the BSL project to something else, as it will clash with the application’s main() routine. Similar thing needs to be done on custom functions with the same name.

     

    Obviously this approach is very high level, but the single-project approach would have to involve at least these steps. You would be effectively manually placing functions into different parts of memory.

    Hi,

    thanks for the suggestions, I think the differential download approach is a possibility I could use. Althought I haven't verified if it works in my setup, yet.

    I am wondering, if the second approach Jace was talking about could achieve the same. Because of other project requirements, I already specified "CODE_SECTION"s for every line of code. The custom BSL and the application are in two independent memory segments. My problem with this approach is, that I guess I have no possibility to duplicate the runtime support libraries.

    I therefore guess that both the BSL and the application are using the same RTS-code including several helper functions (shifts etc.). I believe that this could break my project, if I want to update my application using the custom BSL and a new RTS revision has been released in the meantime. Therefore I would have to prevent the RTS-libs from getting updated, because my BSL code (including its helper functions) must not be corrupted.

    In addition to this, I guess the copytables of the BSL and the application are merged. When the BSL is running, the application variables don't need to be initialized. This would be just a waste of RAM.

    This is the reason why I wanted to have the BSL and the application completely independent from each other. Is my assumption wrong? Or is there any possibility to duplicate the RTS libs and have independent copy tables using the "CODE_SECTION" approach?

    Maybe I should try the differrential download approach.

    Regards

    Marcus

  • in reply to MarcusW
    TI__Genius 11005 points
    Edward, Marcus,

    I wanted to clarify the usage of the "Differential Download" option for MSP430. If this option is on during program load, it keeps track of the programs that are being loaded at each iteration, and compares the changes in the program from the previous iteration to the current iteration to determine the incremental changes and download only the changed sections. The use case for this option is for developers that are developing a large application, and are making minor code changes between iterations during development/debug. This will make it faster to load the application on to the target again.

    This option should NOT be used to load two different programs (in this case, the bootloader and application code), as it might erase the first program when loading the second program as noticed by Edward, and it will also slow down programming as it will try to compare two totally separate programs necessarily.

    The erase option you should be using if loading 2 programs that do not overlap is "Replace written memory locations, retain unwritten memory locations", as we want to retain the first program when loading the second program.

    Sorry for the confusion. Please try out this option and see if this behaves properly for you.

    Thanks,
    Ricky