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.

MSP430FR2512: FRAM devices bootloader (BSL)

Part Number: MSP430FR2512
Other Parts Discussed in Thread: MSPDRIVERLIB

I have some questions regarding the MSP430 FRAM devices bootloader (BSL) functionality:

1. Can the BSL be bypassed and a custom bootloader be installed in FRAM? If so, how will the BSL be bypassed ?

2. Does the bootloader do any initialization of hardware which is mandatory for running an application, or does the application itself initialize the hardware (BSP initialization) ?

3. Is the bootloader using the MSP Peripheral Driver Library?

4. As I understand it, the bootloader is a resident software in ROM which can optionally be configured via a specific FRAM location. Is this config written by an external programmer or by the application code?

5. Who checks the BSL entry sequence on the RST/NMI and TEST pins which decides whether bootloader or application is started? Is there any other resident software on the device which implements the boot functionality? If yes, are there documentation and tests available?

6. Concerning certification, is there a Test Suite (testcases, test procedures, verification results) available for the bootloader software in ROM?

MSP430™ FRAM devices bootloader (BSL)

  • Hi Ralph,

    (1) Yes.  You can add your own BSL in FRAM.  You would access it by having your application jump to the location you place it.  When boot loading a blank device you will have to use the BSL in ROM to get the first image programmed.  There after you can use yours.

    (2) The ROM BSL configures the system clock, I believe at 8MHz, configures the I2C and UART, uses TIMERA for timeout and erases RAM locations 0x2000 - 0x23FF. Here is a link to specific information about FRAM bootloaders. There is additional information about bootloaders here.

    (3) No.  Because of ROM size space constraints it uses bare-metal or accesses the I2C and UART registers directly.

    (4) The ROM bootloader address is mapped to 0x1000 and cannot be changed.

    (5) There are two methods of ROM BSL entry; external (by programmer or host MCU) using RST/NMI and TEST; application vectors to location 0x1000 (for ROM entry) or other location for custom BSL in FRAM.

    (6) No.  There are not certifications for the ROM bootloader.  As with MSPDriverLib and CapTIvate Library, it would be up to the user to perform their own certifications.

  • Hello Dennis,

    Thanks for your detailed answer.

    regarding answer (1):
    this means starting of my own BSL works like for any other application in FRAM (BSL in ROM programs the reset vector at 0xFFFE and new BSL is started after reset), right?

    regarding answer (5):
    Ok, thus in case of BSL entry sequence using RST/NMI and TEST or empty device, the reset vector 0x1000 is used starting the BSL in ROM, otherwise reset vector 0xFFFE is used starting the application.
    Could you please explain how this works in detail, i.e. who generates these reset vectors. Is there some kind of boot code which does HW initialization, checks for the BSL entry sequence and then invokes the application/BSL pointed to by the reset vector?
  • Hi Ralph,

    1. Yes.

    5. Please refer to the section 3.3.2 Hardware BSL Invocation of MSP430™ FRAM devices bootloader (BSL) User's Guide for hardware entrance by RST/NMI and TEST pins. As said in the Table 6-19. Memory Organization and Table 6-2. Interrupt Sources, Flags, and Vectors of the device datasheet, the 0xFFFE is the location of system reset vector and 0x1000 is the start address of BSL functions. Both by hardware and software entrance, the device will run the BSL functions located at 0x1000 to enter the BSL. Otherwise, the device will run the system vector to start the user's application.

**Attention** This is a public forum