Zigbee TI CC2530 Flash programming info

Richard Sharpe realrichardsharpe at gmail.com
Tue Dec 8 10:47:27 EST 2009

Hi folks,

The attached info came from a TI support email. It provides more info
about programming the flash in the cc2530 via the debug interface.

Richard Sharpe
-------------- next part --------------
Here are some answers to commonly asked questions related to programming of a 
CC253x device:

# Q: How do I activate code-protection on CC253x?

Please see CC253x User Guide [1], section "3.4 Lock bits".

The last 16 bytes of the main flash memory acts as flash page lock bits (1 bit 
per flash page -- 0=locked, 1=unlocked). This allows individual enabling of a 
erase/write lock for each flash page. Note that the last bit on the last flash 
page (which is called DBGLOCK bit) not only erase/write locks the last flash 
page, but also locks the debug interface (only some few debug commands are 
allowed). This prevents reading out the programmed flash contents. The only way 
to unlock the debug interface is to do a full chip-erase (CHIP_ERASE) command 
which will erase the chip's whole main flash.

To un-lock a locked flash page (set bit back to 1) you will need to erase the 
flash of the last flash page. This can be done by individually erasing the last 
flash page (unless it too is locked, or if the debug interface is locked), or 
use the CHIP_ERASE debug command to erase it all.

# Q: How do I do programming/reading of the "primary" and "secondary" IEEE802.15.4 
#    MAC address

The so-called "primary" IEEE 802.15.4. MAC address is located in the flash 
information page (not the main flash page), and is a TI registeded, unique, pre-
programmed EUI-64 address which is located at flash info page byte address 
0x00C-0x013 (8 bytes). It is stored in little endian format, with byte0 (LSB) 
@0x00C, and byte7 (MSB) @0x013.

The flash information page is read-only. It can be read via the XDATA memory 
space, since the flash information page is by default mapped into XDATA memory 
at address 0x7800. Hence, the primary address can be read as XDATA memory range 

The "secondary" MAC address is an alternative address that the users can provide 
themselves and it can be stored in normal flash. The supported/suggested 
location used by TI Z-stack/SmartRF Flash Programmer is the last 8 bytes before 
the flash page lock bits.

E.g. for:

CC253xF256 => 0x3FFE8-0x3FFEF, i.e. bytes 0x7E8-0x7EF of flash page 127 (counting 
from page 0, each page is 2048 = 0x800 bytes).
CC253xF128 => 0x1FFE8-0x1FFEF, i.e. bytes 0x7E8-0x7EF of flash page 63.
CC253xF64  => 0x0FFE8-0x0FFEF, i.e. bytes 0x7E8-0x7EF of flash page 32.
CC253xF32  => 0x07FE8-0x07FEF, i.e. bytes 0x7E8-0x7EF of flash page 15.

The secondary address is stored in the main flash, and can thus be read/written 
as normal flash. To read it, you must first map the relevant code bank into the 
upper area of the CODE memory space (address 0x8000-0xFFFF). This is done by 
writing the FMAP special function register to e.g. FMAP=0x07 for CC253xF256 (to map up 
bank 7), before you read from code memory (e.g. CODE space address 0xFFE8-0xFFEF for 

# Q: Do you have an overview of the available debug interface commands, among 
#    which the CMD_BURST_WRITE command (e.g. for example of input parameters and return
#    values)?

The available commands are listed in [1], table "3.2 Debug Commands". But I can 
agree that they clearly could have been explained a bit better.

List of debug commands:

    returns: STATUS byte
WR_CONFIG(uint8 newConfig)
    returns: STATUS byte
    returns: CONFIG byte
    returns: program counter (high + low byte)
    returns: STATUS byte
SET_HW_BRKPNT(uint8 brkPntConfigByte, uint8 addrH, uint8 addrL)
    returns: STATUS byte
    returns: STATUS byte
    returns: STATUS byte
DEBUG_INSTR(uint8 instr0)
    returns: resulting accumulator (A) register value after instruction has been executed
DEBUG_INSTR(uint8 instr0, uint8 instr1)
    returns: resulting accumulator (A) register value after instruction has been executed
DEBUG_INSTR(uint8 instr0, uint8 instr1, uint8 instr2)
    returns: resulting accumulator (A) register value after instruction has been executed
    returns: resulting accumulator (A) register value after instruction has been executed
    returns: byte for which flash bank is currently mapped into upper half of CODE space
    returns: 2 bytes: CHIPID + CHVER register values
BURST_WRITE(uint16 numBytes, uint8 *pBuffer)
    returns: STATUS byte

The BURST_WRITE command has the following input format:
    10000kkk  kkkkkkkk  <databyte1>  <databyte2> ...  <databyte N>

    where the 11 bit kkkkkkkkkkk field specifies the number of data bytes (=N) to be written (minimum 1, maximum 2048 bytes).
    To send 2048 bytes, one has to set kkkkkkkkkkk = 00000000000 (this does not mean zero bytes, which wouldn't make any sense).

# Q: How do I write/set the Flash Write Timing (FWT) setting?

On previous chips, such as CC2430, it was necessary to configure the Flash Write 
Timing setting before doing flash writing.

On the CC253x chips, the required FWT setting will be set/handled automatically 
by hardware, according to the currently used clock speed setting. The FWT 
setting is hidden for the user, and is of no concern for the user.

NOTE: It is recommended to switch to 32 MHz crystal oscillator at full speed (if 
available on the board) to get the fastest flash programming available.

# Q: Do you have any (CC253x specific) documentation concernint timing, for example:
#    - Rise/fall time limits of the signal edges
#    - Minimum/maximum delay between the rising/falling edges of e.g. CD/DD/NRESET
#    - Delays required between Debug interface commands and/or Data-blocks

Some timing requirements for the debug interface signals are listed in [2], see 
the section "DEBUG INTERFACE AC CHARACTERISTICS" on page 12. Some general 
description of the debug interface communication is also found in section "3.2 
Debug Communication" in [1].

# Q: What about timeouts for programming and/or erasing of the flash?

The timing values for the different flash erase/write operations are found in 
chapter 6 (Flash Controller) in [1].

In general, if you are using DMA for flash programming (which is faster than 
doing it with the CPU), you will have to poll the FCTL.BUSY bit to check that it 
has completed, before e.g. continuing with the next chunk/flash page by re-
arming the DMA.

If you do a CHIP_ERASE debug command for erasing the whole main flash, you 
normally poll until bit 7 (CHIP_ERASE_BUSY) of the debug status byte no longer 
is =1.

# Q: What about timeouts for the available acknowledgements on the Debug 
#    interface commands?

The system of polling the Debug Data (DD) line to be low before (attempting) 
reading back the return/output byte(s) is somewhat described in Figure 3-3 and 
Figure 3-4 in [1].

The scheme according to figure 3-4 of reading/clocking out one dummy byte if the 
chip is not ready for response has been implemented in the flash programming 
example code you have received, which might be helpful to look at when you 
implement it on your own hardware.

But if you run into particular problems on this area, let us know and we'll try 
to help.

Please see the attached cc253x_flash_programming_guide_draft.zip for some 
example code on how to do flash programming.

[1] CC253x User Guide -- http://www.ti.com/litv/pdf/swru191
[2] CC2530 Datasheet -- http://www.ti.com/lit/gpn/cc2530

-------------- next part --------------
A non-text attachment was scrubbed...
Name: cc253x_flash_programming_guide_draft.zip
Type: application/zip
Size: 52420 bytes
Desc: not available
URL: <http://lists.en.qi-hardware.com/pipermail/discussion/attachments/20091208/408a0d84/attachment.zip>

More information about the discussion mailing list