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.

MSP430F5438A: Main Memory Bootloader - RESET VECTOR restrictions/Fixed Entry Point

Part Number: MSP430F5438A
Other Parts Discussed in Thread: MSP430F5529,

Greetings,

I'm currently working on a Main Memory Bootloader that can be used to perform firmware upgrade.  I am taking reference from MSPBOOT (slaa600d) and its relevant MSP430F5529 Examples.

The project is using the MSP-TS430PZ5X100 development board that supports MSP430F5438A MCU. The final deliverables will allow the MCU to store the Bootloader, and 2 Applications (APP1 & BACKUP).  The BACKUP application will be untouched by the Bootloader, and it will act as default fallback, in case APP1 is corrupted.

For the start, I've managed to place the Bootloader and the 2 Applications in the lower FLASH (Below 0xFF80). However, I'm only using 'blinkies' as replacements for the actual applications (for now), without any interrupts.

The actual application will be much larger, so the upper FLASH (above 0xFFFF) will definitely be used. This leads to the 2 problems I'm facing at the moment.

  1. RESET VECTOR only takes in 2 bytes (or 16-bits) addresses.
  2. The address of the ENTRY POINT is not fixed, and it seems to be decided by the compiler

For the Bootloader to Jump to APP1, I've used a pointer to an address, specified in the linker command file.
E.g. ((void (*)())  _APP1_RESET_VECTOR) ();

I've tried to change the pointer to ENTRY POINT, instead of RESET VECTOR, but this leads to my problem 2.
As the Bootloader is meant for firmware upgrade, I can't afford varying address for my ENTRY POINT with each new firmware image.

Moreover, my intention is to have the bootloader in the lower FLASH, and the Applications take the upper FLASH.
So, splitting the Application to both lower and upper FLASH is not a possibility.
E.g. .text       : {} >> FLASH | FLASH2 

The current properties for my project on CCS (ver 8.3.1) are:
1) --code_model = large
2) --near_data = none
3) --rom_model

Furthermore, the erase option for my Bootloader is "Main memory Only" and both the applications are using "Differential Download".
So I FLASH my bootloader first, followed by the applications.
While it seems to be working fine now, I'm not sure if there are any problem arises with such download options at a later stage.
This is especially so when I'll be using interrupts later, with the implementation of vector redirection to RAM (with proxy table for each app on FLASH and each application load its own vectors to RAM when the respective app starts)


Therefore, I will like to know how I could proceed to use the upper FLASH memory (above 0xFFFF).
Also, I'm not sure if my problem requires the customization of _system_pre_init( ).
In fact, I'm having difficulty understanding on the customization of _system_pre_init() and boot.c of MSPBOOT.
So, i will gladly appreciate kind explanations and examples, if it is required.

Thank you.

Best regards,
Tan Zhi Wei

  • Hey Tan,

    Welcome to the E2E forums.  It seems like there is a lot to unpack here and I have some questions.  

    First, What is the question about the reset vector?  It seems like you BSL will reside in lower flash and the reset vector will point at it.  Is this your plan as well?  

    Also, I got a little lost of where you are planning to put the applications.  do you want both applications in upper flash?  

    It sounds like most of your questions are around customizing the Linker file so you can carve out different sections for flash for BSL, App1, and app2.  Is this what you think as well? 

    Thanks,

    JD 

  • Hey JD,

    Thanks for the reply.
    I apologized for the confusion. I was trying to be as descriptive as possible.

    Well, the main question is how I could workaround the 16 bits RESET VECTOR, for 20 bits address.

    Both applications will be placed in upper flash. So, the bootloader will jump to the application in the upper flash.
    To avoid any misunderstanding, I'm referring to main memory bootloader and not BSL which resides in protected memory.

    For the bootloader to jump to the app, I used " ((void (*)())  _APP1_RESET_VECTOR) (); "
    Therefore, the bootloader -> reset vector -> entry point -> main

    But the issue is this, reset vector is 16 bits, while my entry point is located in 20 bit address.

    So what I have done to workaround is to jump directly to the entry point instead of going through the reset vector.
    E.g. bootloader -> entry point -> main by using ((void (*)())  _APP1_ENTRY_POINT) ();

    However, this create an entirely new issue which is varying entry point. (problem 2)
    So, there is a need to fix the entry point, which I do not know how I could achieve this.

    Therefore, what I would like to know is how I could have my entry point fixed or if there is a better way to workaround the 16bit reset vector.

    Thanks,
    Zhi Wei


    EDIT: I seem to have found the method to get my entry point fixed, but it will take some time for me to verify and resolve the warnings associated with it. 
    I will probably take the weekend to work on it. In the meantime, if you have other ways to workaround the 16bit reset vector.
    Do let me know. I'll keep you updated with another reply (by Monday), for whatever the outcome would be.
    Thanks for your understanding.

  • Hey Zhi,

    Understood what you are trying to do.  Unfortunately, I'm not very familiar with supporting dual images.  I am reviewing the MSPBoot app note that you mentioned, and I did see there is some descriptions on supporting dual images and a bootloader.   

    Looks like there is a MI and App Manager example for Dual Images in 20Bit large memory models.  Have you looked that these?  

    I think you are going to need to fix your entry points as you suggested and I think that this will require modification of the command linker file.  

    Let us know how the testing goes over the weekend.  Also, maybe someone from the community with experience will comment.  

    Thanks,

    JD

**Attention** This is a public forum