SLAA380B December   2007  – September 2018 MSP430F2616 , MSP430F2617 , MSP430F2618 , MSP430F2619

 

  1.   Migrating From MSP430F16x MCUs to MSP430F261x MCUs
    1.     Trademarks
    2. 1 Comparison of MSP430F1xx and MSP430F2xx Families
    3. 2 Hardware Considerations for MSP430F16x to MSP430F261x Migration
      1. 2.1 Device Package and Pinout
      2. 2.2 Current Consumption
      3. 2.3 Operating Frequency and Supply Voltage
      4. 2.4 Device Errata
    4. 3 MSP430F16x to MSP430F261x Migration – Firmware Considerations
      1. 3.1 CPU and Memory Considerations
        1. 3.1.1 Extended Memory Architecture
        2. 3.1.2 Subroutine Parameter Passing and Stack Frame
        3. 3.1.3 MSP430X Instruction Cycle Count Optimizations
        4. 3.1.4 Device Memory Map
        5. 3.1.5 Information Flash Memory
      2. 3.2 Serial Communication – USART Versus USCI
        1. 3.2.1 UART Mode
        2. 3.2.2 SPI Mode
        3. 3.2.3 I2C Mode
      3. 3.3 Clock System
        1. 3.3.1 LFXT1 and XT2 Oscillators
        2. 3.3.2 Digitally Controlled Oscillator (DCO)
      4. 3.4 Bootloader
      5. 3.5 Interrupt Vectors
      6. 3.6 Beware of Reserved Bits!
      7. 3.7 Timers
      8. 3.8 Analog Comparator
    5. 4 References
  2.   Revision History

3.1.1 Extended Memory Architecture

MSP430F261x MCUs feature an upgraded memory and CPU architecture called MSP430X. The main reason for the architectural upgrade is introduction of an internal 20-bit wide address bus, allowing direct access and branching throughout a 1MB wide memory range without paging. The MSP430X CPU is backward compatible with the MSP430 CPU found on the MSP430F16x.

In general, the MSP430F261x CPU directly executes any MSP430F16x binary code as is. When taking advantage of the extended memory space by placing application code at address 0x10000 and beyond (beyond the first 64KB), one detail needs to be carefully considered. As the program counter (PC) is now 20 bit wide, it is important that the entire code makes use of the CALLA and RETA instructions (instead of CALL and RET). This is to ensure that return addresses are correctly stored and retrieved as 20-bit values. In case of recompiling higher level language code such as C, the compiler manages this automatically. However, in the case of transitioning assembler functions or pre-compiled libraries, this change needs to be incorporated on a source-code level.

An additional detail related to the 20-bit wide PC is that any instruction that directly modifies the PC does so according to the used addressing mode. For example, MOV.W #value,PC clears the upper 4 bits of the PC, because it is a word-wide instruction. This may or may not be desired. Therefore, assembler routines or precompiled libraries directly accessing the PC need to be reviewed and modified as necessary. Again, in case of higher-level language code, a simple recompile automatically takes care of these modifications.