SLAA600E June   2013  – January 2024

 

  1.   1
  2.   Abstract
  3.   Trademarks
  4. 1Introduction
    1. 1.1 Glossary
    2. 1.2 Conventions
  5. 2Implementation
    1. 2.1 Main
    2. 2.2 Application Manager
      1. 2.2.1 Boot and Application Detection
        1. 2.2.1.1 Force Bootloader Mode
        2. 2.2.1.2 Application Validation
        3. 2.2.1.3 Jump to Application
      2. 2.2.2 Vector Redirection
      3. 2.2.3 Interrupt Vectors in Flash Devices
      4. 2.2.4 Dual Image Support
        1. 2.2.4.1 Jumping to Application in Dual Image Mode
    3. 2.3 Memory Interface (MI)
      1. 2.3.1 Dual Image Support
    4. 2.4 Communication Interface (CI)
      1. 2.4.1 Physical-DataLink (PHY-DL)
        1. 2.4.1.1 I2C
          1. 2.4.1.1.1 Time-out Detection
        2. 2.4.1.2 UART
        3. 2.4.1.3 SPI
        4. 2.4.1.4 CC110x
        5. 2.4.1.5 Comm Sharing
      2. 2.4.2 NWK-APP
        1. 2.4.2.1 BSL-Based Protocol
          1. 2.4.2.1.1 Security
          2. 2.4.2.1.2 BSL-Based Protocol using CC110x
          3. 2.4.2.1.3 Examples Using I2C
          4. 2.4.2.1.4 Examples Using UART or CC110x
  6. 3Customization of MSPBoot
    1. 3.1 Predefined Customizations
  7. 4Building MSPBoot
    1. 4.1 Starting a New Project
      1. 4.1.1 Creating a New MSPBoot Project
        1. 4.1.1.1 MSPBootProjectCreator.pl
        2. 4.1.1.2 Importing Project Spec File in CCS
        3. 4.1.1.3 Modifying Generated Source Code
          1. 4.1.1.3.1 Modifying MSPBoot Main.c
          2. 4.1.1.3.2 Modifying TI_MSPBoot_Config.h
          3. 4.1.1.3.3 Modifying TI_MSPBoot_CI_PHYDL_xxxx_xxx.c
          4. 4.1.1.3.4 Modifying TI_MSPBoot_AppMgr.c
          5. 4.1.1.3.5 Modifying Application Main.c
          6. 4.1.1.3.6 Modifying TI_MSPBoot_Mgr_Vectors_xxxx.c
      2. 4.1.2 Loading Application Code With MSPBoot
        1. 4.1.2.1 Convert Application Output Images
    2. 4.2 Examples
      1. 4.2.1 LaunchPad Development Kit Hardware
      2. 4.2.2 CC110x Hardware
      3. 4.2.3 Building the Target Project
      4. 4.2.4 Building the Host Project
      5. 4.2.5 Running the Examples
  8. 5References
  9. 6Revision History

4.2.5 Running the Examples

The host project sends two different images to the target device, using a push button for user interaction. USB connection to a computer is not required on either LaunchPad development kit to run the demo; however, each kit should be powered either by a USB connection through the eZ-FET or with steady 3.3-V external power supply to VCC and GND pins (ensure that the eZ-FET is disconnected in this instance). The demo is run using these steps regardless of communication type or image model used:

  1. Build and download the MSPBoot as described in Section 4.2.3 and build App1 and App2.
  2. Convert App1 and App2 according to Section 4.1.2.1.
  3. Build and download the host application as described in Section 4.2.4.
  4. Connect the boards according to the desired communication type (I2C, UART, or SPI with CC110x).
    1. Each host project contains a commented diagram at the start of code describing the proper connections.
  5. Reset and execute code in both devices.
  6. To enter the target bootloader mode (indicated by both LED1 and LED2 remaining on):
    1. If the target does not have a valid application (default), the target stays in bootloader mode.
    2. Bootloader mode can be forced in hardware by pressing and holding the S2 button on the target device while pressing and releasing the reset button.
    3. If running an application:
      1. APP1 jumps to bootloader mode when the S2 button is pressed on the target device.
      2. APP2 jumps to bootloader mode when it receives the Force Boot command (supported only if CI PHY-DL is shared).
  7. Press the S2 button on the host board. The host device performs the following sequence of commands:
    1. Toggles LED1 twice.
    2. Sends “Force Boot” command (0xAA).
      1. If the target device is already in bootloader mode, it discards the packet, because the CRC is incorrect.
      2. If the target is running APP2, the target device enters bootloader mode.
    3. Requests the bootloader version (sends the TX_VERSION command).
      1. If the target response is 0xA1 (expected from BSL protocol), the host continues.
      2. If the target response is any other value, the host aborts transaction.
    4. Erases the target application area (sends the ERASE_APP command).
    5. Sends APP1 (uses the RX_DATA_BLOCK commands).
    6. Programs CRC of APP1 (uses the RX_DATA_BLOCK command).
    7. Forces the target application to run (sends the JUMP2APP command).
    8. Toggles LED1 twice to indicate successful transfer, and keeps LED1 on to show that the host is now ready to send APP2.
  8. Target starts running APP1 upon completion of transfer.
    1. The target device blinks LED1.
    2. LED1 blinks at a periodic interval using the timer.
    3. Press the S2 button on the target board to enter bootloader mode.
  9. With the target in bootloader mode, press the S2 button on the host board to send APP2. When finished and done toggling, LED1 of the host board stays off to indicate that APP1 is now ready to be sent.
  10. Target starts running APP2 upon completion of transfer.
    1. The target device blinks LED2.
    2. Press the S2 button on the target board to toggle LED2.
    3. Because the CI is initialized, the host can send a Force Boot command to force bootloader mode in the target device at the start of a new transfer sequence.
  11. Press the S2 button on the host to start a new sequence sending APP1 again.

    Dual-image mode contains a brief pause from the host after the transfer is complete while it validates the download area, transfers the memory into the application space, and erases the download area after the application area is validated by a CRC-CCITT check.