Moving out!

As you might have noticed, I am starting to move my posts to my new blog. In the future, I will not publish any new post in this blog. Please feel free to visit my new blog however: http://embedded-funk.net/

CC3000 Basic WiFi Host

This post has been removed to this link.

Using MSP430F5xx/6xx BSL Flash Memory For Application Code/Data

On the MSP430F5xx/6xx devices, the BSL (Bootstrap Loader) is stored on a special on-chip Flash memory area instead of on-chip ROM as the other device families (MSP430F1xx, MSP430x2xx, MSP430F4xx). Thus if the BSL is not used, it is possible to use the BSL Flash memory area for user's application code and data. The following guide shows an example on how to use the Flash BSL memory for storing application code as well as application constant data. The example will be based on CCSTUDIO v5.5 implementation for MSP430F5529 running on MSP-TS430PN80USB development kit.

MSP430F5xx/6xx BSL Flash Memory Characteristic

Referring to the MSP430F5529 device specific datasheet - Table 5 "Memory Organization" at page 22, the BSL Flash Memory is basically located at address 0x1000 - 0x17FF, divided into 4 segments: BSL0-3.

The access to the BSL Flash Memory is managed by the SYSBSLC register which is described in the MSP430F5xx/6xx Family User's Guide document chapter 1.15.2 "SYSBSLC Register".

Besides the BSL itself, this special protectable flash memory area is used to store some configurations which is used by the bootcode during startup. These configurations is described in the SLAA450 application note - chapter 1.1.2 "BSL Reserved Memory Locations".

Therefore it is very important to keep these reserved memory locations intact to ensure the proper device operation.

Example Code Implementation

The example code implementation can be found on this link. The code is described in detail as follows.

Defining BSL Flash Segment in The Linker Command File

Per default the linker command file of CCSTUDIO doesn't contain any definition for BSL Flash segments BSL0-3. Thus it is necessary to defined the BSL Flash memory are in both MEMORY and SECTIONS part of the lnk_msp430f5529.cmd linker command file as follows:

/****************************************************************************/
/* SPECIFY THE SYSTEM MEMORY MAP                                            */
/****************************************************************************/

MEMORY
{
    .......................
    BSL0   : origin = 0x1000, length = 0x0200
    BSL1   : origin = 0x1200, length = 0x0200
    BSL2   : origin = 0x1400, length = 0x0200
    BSL3   : origin = 0x1600, length = 0x01F2
    BSL3_RESERVED  : origin = 0x17F2, length = 0x000E
    .......................
}

/****************************************************************************/
/* SPECIFY THE SECTIONS ALLOCATION INTO MEMORY                              */
/****************************************************************************/

SECTIONS
{
    .......................
    .bsl0      : {} > BSL0
    .bsl1      : {} > BSL1
    .bsl2      : {} > BSL2
    .bsl3      : {} > BSL3
    .bsl3_res  : {} > BSL3_RESERVED
    .......................
}

Using The BSL Flash Segment in The Application Code

After the new .bslx sections defined in linker command file, they can be used to store application code or constants as described in this guide from TI processors wiki.

The using_bsl_flash_mem.c example uses the .bsl0 to store some application constant data as follows:

// constants to be placed in BSL Flash memory
#pragma SET_DATA_SECTION (".bsl0")
const uint8_t const1 = 123;
const uint16_t const2 = 2500;
const uint32_t const3 = 1323;
#pragma SET_DATA_SECTION ()

The example also uses the .bsl1 and .bsl2 for storing application code/functions:

#pragma CODE_SECTION (addition, ".bsl1")
static uint16_t addition(uint16_t a, uint16_t b)
{
  return (a+b);
}

......................

#pragma CODE_SECTION (substraction, ".bsl2")
static uint16_t substraction(uint16_t a, uint16_t b)
{
  return (a-b);
}

Both constants and codes stored in the above can then be accessed by the rest of application code just like normal constants/codes which is shown in the main function of the example code:

To confirm whether the constants and the application codes are really compiled and stored into the BSL Flash memory area, we shall check the generated MAP file (or check the "Memory Browser" window in the CCSTUDIO debug window as shown above):

SECTION ALLOCATION MAP

 output                                  attributes/
section   page    origin      length       input sections
--------  ----  ----------  ----------   ----------------
................

.bsl1      0    00001200    00000012     
                  00001200    00000012     using_bsl_flash_mem.obj (.bsl1:addition)

.bsl2      0    00001400    00000012     
                  00001400    00000012     using_bsl_flash_mem.obj (.bsl2:substraction)

................

GLOBAL SYMBOLS: SORTED ALPHABETICALLY BY Name 

address    name
--------   ----
................
000017f2   bsl_reserved
00001000   const1
00001002   const2
00001004   const3

Enabling Protection to BSL3 Segment 

As mentioned above, it is necessary to protect the BSL3 reserved memory which contains the BSL Reserved Memory Locations in order to ensure proper device operation. This is done basically by setting the SYSBSLC register during startup (_system_pre_init() function):

int _system_pre_init(void)
{
  // stop WDT
  WDTCTL = WDTPW + WDTHOLD;

  // make sure to release protection for the used BSL flash memory
  // and keep the protection for BSL3 containing reserved area used
  // for JTAG lock, etc.
  SYSBSLC = SYSBSLPE | SYSBSLOFF;

  // Perform C/C++ global data initialization
  return 1;
}

While the .bsl_reserved section is filled up with 0xFFs:

// reserved memory location - do not touch
#pragma RETAIN(bsl_reserved)
#pragma DATA_SECTION(bsl_reserved, ".bsl3_res")
const uint8_t bsl_reserved[0x0E] = {0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF,
    0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF};

Enabling Access to BSL Flash Memory

Normally, the access to the BSL Flash memory is by default disabled in the CCSTUDIO IDE. Therefore it is necessary to enable the CCSTUDIO debug setting to be able to download the code into the protected BSL flash memory area as described here.

Writing C Code Smartly (1) - Use Your C Preprocessor as Your Calculator

This post has been removed to this link.

RF Hardware Tutorial(s) for Beginners

So for my personal record, i am listing some list of RF Hardware Tutorial(s) which i have found in this post. I will try to extend the list over time.

http://e2e.ti.com/support/low_power_rf/f/155/p/30664/219091.aspx

http://www.ti.com/lit/ml/slap127/slap127.pdf

Running Contiki 2.7 CC2538DK Demo

This post has been removed to this link.

Compiling Contiki 2.7 Demo for CC2538DK on MS Windows

This post has been removed to this link.