SLAU319AF July   2010  – September 2022

 

  1.   Abstract - MSP430™ Flash Devices Bootloader (BSL)
  2.   Trademarks
  3. 1Introduction
    1. 1.1 Supplementary Online Information
    2. 1.2 Overview of BSL Features
    3. 1.3 BSL Invocation
      1. 1.3.1 Hardware BSL Invocation
        1. 1.3.1.1 MSP430 Devices With Shared JTAG Pins
          1. 1.3.1.1.1 Factors That Prevent BSL Invocation With Shared JTAG Pins
        2. 1.3.1.2 MSP430 Flash Devices With Dedicated JTAG Pins
          1. 1.3.1.2.1 Factors That Prevent BSL Invocation With Dedicated JTAG Pins
        3. 1.3.1.3 Devices With USB
      2. 1.3.2 Software BSL Invocation
    4. 1.4 UART Protocol
    5. 1.5 USB Protocol
  4. 2Bootloader Protocol – 1xx, 2xx, and 4xx Families
    1. 2.1 Synchronization Sequence
    2. 2.2 Commands
      1. 2.2.1 Unprotected Commands
      2. 2.2.2 Password Protected Commands
    3. 2.3 Programming Flow
    4. 2.4 Data Frame
      1. 2.4.1 Data-Stream Structure
      2. 2.4.2 Checksum
      3. 2.4.3 Example Sequence
      4. 2.4.4 Commands – Detailed Description
        1. 2.4.4.1  General
        2. 2.4.4.2  RX Data Block
        3. 2.4.4.3  RX Password
        4. 2.4.4.4  Mass Erase
        5. 2.4.4.5  Erase Segment
        6. 2.4.4.6  Erase Main or Info
        7. 2.4.4.7  Erase Check
        8. 2.4.4.8  Change Baud Rate
        9. 2.4.4.9  Set Memory Offset
        10. 2.4.4.10 Load PC
        11. 2.4.4.11 TX Data Block
        12. 2.4.4.12 TX BSL Version
    5. 2.5 Loadable BSL
    6. 2.6 Exiting the BSL
    7. 2.7 Password Protection
    8. 2.8 Code Protection Fuse
    9. 2.9 BSL Internal Settings and Resources
      1. 2.9.1 Chip Identification and BSL Version
      2. 2.9.2 Vectors to Call the BSL Externally
      3. 2.9.3 Initialization Status
      4. 2.9.4 Memory Allocation and Resources
  5. 3Bootloader Protocol – F5xx and F6xx Families
    1. 3.1 BSL Data Packet
    2. 3.2 UART Peripheral Interface (PI)
      1. 3.2.1 Wrapper
      2. 3.2.2 Abbreviations
      3. 3.2.3 Messages
      4. 3.2.4 Interface Specific Commands
        1. 3.2.4.1 Change Baud Rate
    3. 3.3 I2C Peripheral Interface
      1. 3.3.1 I2C Protocol Definition
      2. 3.3.2 Basic Protocol With Byte Level Acknowledge
      3. 3.3.3 I2C Protocol for BSL - Read From Slave
      4. 3.3.4 Acknowledge (ACK)
      5. 3.3.5 Wrapper
    4. 3.4 USB Peripheral Interface
      1. 3.4.1 Wrapper
      2. 3.4.2 Hardware Requirements
    5. 3.5 BSL Core Command Structure
      1. 3.5.1 Abbreviations
      2. 3.5.2 Command Descriptions
    6. 3.6 BSL Security
      1. 3.6.1 Protected Commands
      2. 3.6.2 RAM Erase
    7. 3.7 BSL Core Responses
      1. 3.7.1 Abbreviations
      2. 3.7.2 BSL Core Messages
      3. 3.7.3 BSL Version Number
      4. 3.7.4 Example Sequences for UART BSL
    8. 3.8 BSL Public Functions and Z-Area
      1. 3.8.1 Starting the BSL From an External Application
      2. 3.8.2 Return to BSL Function Description
  6. 4Bootloader Hardware
    1. 4.1 Hardware Description
      1. 4.1.1 Power Supply
      2. 4.1.2 Serial Interface
        1. 4.1.2.1 Level Shifting
        2. 4.1.2.2 Control of RST/NMI and TEST or TCK Pins
      3. 4.1.3 Target Connector
      4. 4.1.4 Parts List
  7. 5Differences Between Devices and Bootloader Versions
    1. 5.1 1xx, 2xx, and 4xx BSL Versions
    2. 5.2 Special Consideration for ROM BSL Version 1.10
    3. 5.3 1xx, 2xx, and 4xx BSL Known Issues
    4. 5.4 Special Note on the MSP430F14x Device Family BSL
    5. 5.5 F5xx and F6xx Flash-Based BSL Versions
  8. 6Bootloader PCB Layout Suggestion
  9. 7Revision History

3.8.1 Starting the BSL From an External Application

Setting the program counter to the memory location 0x1000 starts the BSL. The stack is always reset, and RAM is cleared. It should be noted that the GIE bit is not disabled, so this should be done by the calling application if interrupts are not desired and appropriately returned from "Return to BSL" if they are used.

Because the stack is reset, the location 0x1000 can also be called as a C function, as in the following example code:

__disable_interrupt();
((void (*)())0x1000)();

If a USB stack is operating before the USB BSL is invoked, this USB stack must be disconnected first. The following example shows the recommended sequence in C:

TI recommends clearing the configuration of any module registers that are used in the BSL application, because the configuration for the external application can interrupt the BSL application and cause unexpected behavior. One example is that in the USB BSL, the Timer_B module is used in clock initialization. If Timer_B is also used in the external application, this might cause a failure in BSL initialization.

__disable_interrupt();
USBKEYPID = 0x9628;     // Unlock USB configuration registers
USBCNF &= ~PUR_EN;      // Set PUR pin to hi-Z, logically disconnect from host
USBPWRCTL &= ~VBOFFIE;  // Disable VUSBoff interrupt
USBKEYPID = 0x9600;     // Lock USB configuration register
__delay_cycles(500000);
((void (*)())0x1000)(); // Call BSL

TI recommends testing this sequence on various hosts.