SLAA450G April   2010  – April 2020

 

  1.   Creating a Custom Flash-Based Bootloader (BSL)
    1.     Trademarks
    2. 1 5xx and 6xx Bootloader Customization
      1. 1.1 BSL Memory Layout
        1. 1.1.1 Z-Area
        2. 1.1.2 BSL Reserved Memory Locations
      2. 1.2 Device Start-up Sequence
        1. 1.2.1 BSL Protect Function
          1. 1.2.1.1 Protection of BSL Memory
          2. 1.2.1.2 Checking for BSL Invoke
      3. 1.3 TI-Supplied BSL Software
        1. 1.3.1 Software Overview
        2. 1.3.2 Software File Details
          1. 1.3.2.1 BSL430_Low_Level_Init.s43 (IAR) / BSL430_Low_Level_Init.asm (CCS)
          2. 1.3.2.2 BSL_Device_File.h
          3. 1.3.2.3 lnk430FXXXX_BSL_AREA.xcl (IAR) / MSP430Fxxxx_BSL.cmd (CCS)
        3. 1.3.3 Known Limitations in CCS CSL Code Example
          1. 1.3.3.1 Memory Allocation of BSL Code Under Linker Command File
          2. 1.3.3.2 BSL Functions Supported in the Default Setting Project
          3. 1.3.3.3 How to Accomodate Full Function of BSL
          4. 1.3.3.4 Using Modified boot_hook.h and boot.c (CCS Only)
      4. 1.4 Creation of Custom Peripheral Interface
        1. 1.4.1 PI_init ()
        2. 1.4.2 PI_receivePacket()
        3. 1.4.3 PI_sendData(int bufSize)
      5. 1.5 BSL Development and Debug
        1. 1.5.1 Development and Testing
        2. 1.5.2 Special Notes and Tips
        3. 1.5.3 USB BSL External Oscillator Frequency
    3. 2 G2xx Bootloader Creation and Customization
      1. 2.1 Target System Specification
      2. 2.2 BSL Specification
        1. 2.2.1 Functionality
          1. 2.2.1.1 Entry Sequence
          2. 2.2.1.2 Synchronization
          3. 2.2.1.3 Erasing Previous Flash Content
          4. 2.2.1.4 Receiving and Writing New User Data
          5. 2.2.1.5 Data Verification
        2. 2.2.2 Memory Footprint
        3. 2.2.3 Peripherals
      3. 2.3 Implementation
        1. 2.3.1 BSL Assembler Code
          1. 2.3.1.1 Save DCO Calibration Data
          2. 2.3.1.2 Linker Command File
            1. 2.3.1.2.1 Locating the Linker Command File
            2. 2.3.1.2.2 Modify Linker File
            3. 2.3.1.2.3 Force the IDE to Use Custom Linker File
          3. 2.3.1.3 Project Settings
        2. 2.3.2 User Application
      4. 2.4 BSL Operation
        1. 2.4.1 Hardware Setup
        2. 2.4.2 Connection to Host
          1. 2.4.2.1 Determining COM Port
          2. 2.4.2.2 Setup of COM Port
        3. 2.4.3 Operate BSL - Standard Sequence
        4. 2.4.4 Create New Code to Download Through BSL
          1. 2.4.4.1 Create Custom Application
          2. 2.4.4.2 Save Calibration Data
          3. 2.4.4.3 Make User Application Code a BSL Update File
            1. 2.4.4.3.1 Using CCS
            2. 2.4.4.3.2 Using IAR
          4. 2.4.4.4 Obtaining XOR Checksum
            1. 2.4.4.4.1 Send User Data
            2. 2.4.4.4.2 Read Checksum
            3. 2.4.4.4.3 Send Acquired Checksum
            4. 2.4.4.4.4 Verify Data
            5. 2.4.4.4.5 Save Checksum
        5. 2.4.5 Getting Ready for Production
    4. 3 Frequently Asked Questions (FAQ)
  2.   Revision History

1.3.1 Software Overview

The TI-supplied BSL is written in such a way that it is extremely modular. Depending on the level of customization needed, various source files can be reused or replaced.

The three main sections of BSL code are:

Peripheral Interface

This section of code has responsibility for receiving and verifying a BSL Core Command. To accomplish this, the code can use any hardware or protocol (wrapper bytes or other options). The actual transmission mechanism and protocol are irrelevant for the rest of the BSL. What is important is that when the BSL is called upon to receive a packet, it does not return until it has correctly received all data sent to it. Because the BSL is used for erasing and programming user memory, the Peripheral Interface cannot use flash-based interrupt vectors. Either event polling or RAM-based interrupt vectors must be used.

Command Interpreter

This section of code interprets the supplied BSL Core Command bytes. The code can assume that the Peripheral Interface has successfully received the bytes without error but not necessarily that the bytes are correct for the BSL protocol (for example, if an incorrect command is sent). This code interprets the received Core Command according to the BSL Core Command list (see the MSP430™ Flash Device Bootloader (BSL) User's Guide) and executes received commands by calling the BSL API.

BSL API

This section of code provides an abstraction layer between the command interpreter and the memory being written to or read from. It handles all aspects of unlocking memory, writing to it, reading from it, and CRCs. It also, whenever possible, is the section of code where security is handled. This allows the command interpreter to simply make requests and send responses without being concerned with security issues. This model also allows for extremely secure custom BSLs to be made, as it is assumed the BSL API is the least likely section to be replaced in any custom BSL, so any custom BSL benefits from TI-supplied security checks and measures.