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.

LP-MSPM0G3507: Linker script for application when secondary BSL is used

Part Number: LP-MSPM0G3507
Other Parts Discussed in Thread: MSPM0G3507, SYSCONFIG

I am interested in setting up a secondary BSL, and have looked at the example provided in the MSPM0 SDK, I can see from the linker script that its vector table and code appear to reside in flash between 0x1000 and 0x2000. That all seems to make sense.

Is there an example of an application that will work alongside this? I assume that I'll need to configure the application's linker script to avoid those addresses? Is it expected that I'd place the application's vector table at 0x0000 (as it "normally" is) and then the application code/data from 0x2000 upwards? This seems like it would potentially waste the space between the top of the vector table and 0x1000. Or is there some part of the addressing scheme I've misunderstood?

  • Hello Alan,

    According to the NONMAIN configuration of the secondary BSL code in our SDK, The Flash area that is statically write protected is 0x1000 ~ 0x3000, the application code starts from 0x3000, and the vector starts from 0x0000. e it would potentially waste the space between the top of the vector table and 0x1000. If you want to fully utilize Flash, you can write the secondary BSL code at the bottom of the Flash.

    Best Regards,

    Janz Bai

  • Ah yes, I misread the size of the flash allocated to the secondary bootloader, thanks.

    I take it that there is no example for such an application that would work with this?  I think I understand what changes need to be made to the linker script to make it work, though.

    You mention that the secondary bootloader could be put at the "bottom" of flash - do you mean at address 0x0000?  Isn't that where the vector table for the application must go?  Or do you mean that the secondary bootloader could be put at the highest-addressed sector in flash - in which case I'd have to write-protect a full 8kB sector, using even more flash than the original suggestion?

  • Hello Alan,

    We have demo code in SDK. you can download the latest version SDK on Ti.com, and you can find it in "examples -> nortos -> LP_MSPM0G3507 -> bsl"

    The "bottom" I mean is the "top" you mean. 0x0000 is used to place the vector.

    Best Regards,

    Janz Bai

  • OK - so the suggested location for the secondary bootloader in order to maintain a contiguous application area would be the one that requires a larger sector being dedicated to the bootloader?

    I had found the examples that you suggested, but they all appear to be either extensions/plugins to the ROM BSL or an example of a secondary BSL.  Is one of them an application that will work alongside a secondary BSL, so that I can check my understanding of the linker file against one you have provided?

  • Hello Alan,

    As shown in our SDK, secondary BSL is placed from 0x1000 to 0x3000. In the sysconfig of the demo code, you can find that the 0x1000 ~0x3000 is statically write protected. And the application code is placed from 0x3000 ~. This allocation method is suitable for most cases.

    Place the BSL code at the top of the Flash is another allocation method which can help you use all the Flash space possibly. Because you can place the application code close to the vector.

    In the application of BSL, the "secondary BSL" demo code will be downloaded to the target device, and you can use the BSL GUI as the host device. You can find the BSL GUI from “SDK -> tools -> bsl-> BSL_GUI_EXE" 

    Best Regards,

    Janz Bai