SLAA721E October   2016  – March 2020 MSP430FR5969 , MSP430FR5969-SP , MSP430FR5994 , MSP430FR6989

 

  1.   Trademarks
  2. 1Introduction
    1. 1.1 Glossary
    2. 1.2 Conventions
  3. 2Implementation
    1. 2.1 Main
    2. 2.2 Application Manager
      1. 2.2.1 Bootloader and Application Detection
        1. 2.2.1.1 Forcing Bootloader Mode
        2. 2.2.1.2 Application Validation
        3. 2.2.1.3 Jumping to Application
      2. 2.2.2 Memory Assignment
      3. 2.2.3 Interrupt Vectors in FRAM Devices
    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 UART
        2. 2.4.1.2 SPI
        3. 2.4.1.3 CC110x
        4. 2.4.1.4 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 UART or CC110x
  4. 3Customization of MSP430FRBoot
    1. 3.1 Predefined Customizations
  5. 4Building MSPBoot
    1. 4.1 LaunchPad™ Development Kit Hardware
    2. 4.2 CC110x Hardware
    3. 4.3 Software
      1. 4.3.1 Building the Target Software
      2. 4.3.2 Convert Application Output Images
      3. 4.3.3 Generating Linker Files
  6. 5Demo Using FRAM LaunchPad Development Kit as Host
    1. 5.1 Hardware
    2. 5.2 Building the Host Project
    3. 5.3 Running the Demo
  7. 6Porting the target side example projects to other MSP430FR devices
  8. 7References
  9. 8Revision History

5.3 Running the Demo

The host LaunchPad development kit 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 a steady 3.3-V external power supply to the VCC and GND pins (ensure that the eZ-FET is disconnected in this instance). Because both the host and target LaunchPad development kits are of the same derivative, it might be helpful to label each board accordingly to avoid confusion. The demo is run using these steps, regardless of communication type or image mode used:

  1. Build and download MSPBoot as described in Section 4.3.1, and build App1 and App2.
  2. Convert App1 and App2 according to Section 4.3.2.
    Note:

    Batch file PrepareCCSOutput_[FR derivative].bat shows how to convert to C and copy the output files. In this host implementation, the MSP430 MCU holds the target image without CRC, so it calculates the CRC value assuming that unimplemented locations are 0xFF.

  3. Build and download the host application as described in Section 5.2.
  4. Connect the boards according to the desired communication type (UART as described in Section 5.1 or one of the CC110x solutions described in Section 4.2).
  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 S1 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 0xA0 (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 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 S1 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.

Note:

Due to a pin conflict on the MSP-EXP430FR2433, disconnet LED2 from P1.1 by removing the jumper and physically wire to P1.2, instead.