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.2.1 BSL Protect Function

The BSL Protect function is called after each BOR and before user code is executed. There is no time and functionality limit placed on this code; however, if this function does not return, the device is rendered unresponsive. Excessively long delays in the return functions could lead to problems during debug. At its most basic, the BSL Protect function should perform two essential operations: protect the BSL memory and determine whether the BSL or user code should be executed after exiting the BSL Protect function.

The BSL Protect function is called with the stack pointer set to a default location, which is dependent on the device. Changing the stack pointer or manipulation of the stack pointer data values will most likely lead to a unresponsive device. In this case, nothing, not even reprogramming, will be possible. On some devices, the stack pointer space is very limited, and extensive use of the stack pointer within the BSL Protect function could lead to memory overflows. To ensure proper behavior, the stack access should be limited or the stack pointer should be moved to another location. To make sure that the device returns from the BSL Protect function correctly, the stack pointer must be restored before returning.