Compiler/CC2530: abort problem of changing cc2530 secondary mac

Hi Winkeys,

The flash information page (2 KB) is mapped into the address range (0x7800–0x7FFF). This is a read-only area and contains various information about the device, including a unique IEEE address from the TI range of addresses.

Therefore you are unable to modify HAL_FLASH_IEEE_PAGE during runtime.  You are able to create a custom IEEE address which Z-Stack will use for its application in zmain_ext_addr.

Regards,
Ryan

Hi Ryan:

The flash information page (2 KB) is mapped into the address range (0x7800–0x7FFF). This is a read-only area and contains various information about the device, including a unique IEEE address from the TI range of addresses.
---winkeys: yes,I know that the flash information page(0x7800–0x7FFF) is read-only, and the primary IEEE address is stored there. I just want to change the secondary IEEE address which is stored at page HAL_FLASH_IEEE_PAGE(127) and offset HAL_FLASH_IEEE_OSET(2024).

Therefore you are unable to modify HAL_FLASH_IEEE_PAGE during runtime. You are able to create a custom IEEE address which Z-Stack will use for its application in zmain_ext_addr.
---winkeys:In my previous attachment(code_en.txt), you can get that the function “main()” calls my own test function "zigbee_adp_changeMac_test()" first, and then calls function "zmain_ext_addr()".
By the way, I've run the test code directly in function "zmain_ext_addr()" before. Both have the same wrong results.

Other experiments I've done are as follows:
<1>Using flash programmer tool can change the secondary MAC.however, Our product line can not use this solution because of the production process.
<2>Using ccdebugger, clicking "download and debug" at IAR, my own code can change the secondary MAC successfully this time.
<3>With ccdebugger is plugging, power down and power on the CC2530, and my own code can not change the secondary MAC successfully.
<4>Without ccdebugger is plugging, power down and power on the CC2530, and my own code can not change the secondary MAC successfully.

So,what's the difference between <2> and <3> above? The difference is, does ccdebugger give extra power?
Some people say it's the power supply reason.(e2echina.ti.com/.../53553). Is it right?
Or ,are there Other reasons？

===============================================

Supplementary notes:

In my previous attachment(code_en.txt), I directly access the secondary MAC as follows:
HalFlashErase(127);
HalFlashWrite(0xFFFA, testMac1, 2);
HalFlashRead(HAL_FLASH_IEEE_PAGE, HAL_FLASH_IEEE_OSET, usrDefSecondaryMac, Z_EXTADDR_LEN);

The function "HalFlashWrite" prototype is as follows in hal_flash.c :
HalFlashWrite(uint16 addr, uint8 *buf, uint16 cnt)
* @param addr - Valid HAL flash write address: actual addr / 4 and quad-aligned.
* @param buf - Valid buffer space at least as big as 'cnt' X 4.
* @param cnt - Number of 4-byte blocks to write.
so the secondary MAC addr =( (HAL_FLASH_IEEE_PAGE * HAL_FLASH_PAGE_SIZE ) + HAL_FLASH_IEEE_OSET )/4
= (127*2048 + 2024)/4
= 0xFFFA

Winkeys,

What voltage are you supplying to your device independent of the CC-DEBUGGER?  Two volts is required for device operation and to safely read/write internal flash.  Have you tried replicating this issue with a newer Z-Stack solution, such as Z-Stack HA 1.2.2a (from Z-STACK-ARCHIVE) or Z-Stack 3.0.2?

Information regarding lock bits from the User's Guide: "For software and/or access protection, a set of lock bits can be written to the upper available flash page—the lock-bit page. The lock-bit structure consists of 128 bits where the first (FLASH_PAGES-1) each corresponds to the first flash pages available in the device. The last bit (at the highest address) is the debug lock bit (see Table 3-5). The structure starts at address 0x7FF0 (address 0xFFF0 in XDATA) when the upper flash bank is mapped in, and occupies 16 bytes. The rest of the lock-bit page can be used to store code or constants, but cannot be changed without entering debug mode."

I recommend that you store the secondary MAC address in the last 8 bytes before the flash page lock bits, 0x7E8-0x7EF of flash page 127. http://lists.en.qi-hardware.com/pipermail/discussion/2009-December/001313.html

Regards,
Ryan

Hi Ryan:

What voltage are you supplying to your device independent of the CC-DEBUGGER?    

---winkeys: Our hard desinger has test the voltage. In the case of CCDEBUGGER(IAR download and debug) and no CCDEBUGGER, the voltage basically keeps the same at 3.316v. Is it OK?

                  In the case of no CCDEBUGGER, the port P1_6 stays high. However, In the case of CCDEBUGGER(IAR download and debug) , the port P1_6 changes to halt-high for a moment, and then stays high. What should be the correct value? 

Have you tried replicating this issue with a newer Z-Stack solution, such as Z-Stack HA 1.2.2a (from Z-STACK-ARCHIVE) or Z-Stack 3.0.2?

  ---winkeys: OK, I'll try the results with the original version 2.5.1a, and then other version. and then tell you the results.

Information regarding lock bits from the User's Guide: "For software and/or access protection, a set of lock bits can be written to the upper available flash page—the lock-bit page. The lock-bit structure consists of 128 bits where the first (FLASH_PAGES-1) each corresponds to the first flash pages available in the device. The last bit (at the highest address) is the debug lock bit (see Table 3-5). The structure starts at address 0x7FF0 (address 0xFFF0 in XDATA) when the upper flash bank is mapped in, and occupies 16 bytes. The rest of the lock-bit page can be used to store code or constants, but cannot be changed without entering debug mode."

I recommend that you store the secondary MAC address in the last 8 bytes before the flash page lock bits, 0x7E8-0x7EF of flash page 127. http://lists.en.qi-hardware.com/pipermail/discussion/2009-December/001313.html

   ---winkeys: I checked the information you gave me. My own code is consistent with the information and I did not change the position. In the print I provided earlier, that the FCTL = 0x28 means "abort". But the page-lock bits are all 0xFF in the print.

anyway. About the follow link inforation you gave me,Should I modify FMAP manually when I use HalFlashWrite function? And Please make sure whether or not  I should modify my own f8w2530.xcl in the attachment?

"
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
CC253xF256).
"

/**************************************************************************************************
  Filename:       f8w2530.xcl
  Revised:        $Date: 2012-03-29 12:09:02 -0700 (Thu, 29 Mar 2012) $
  Revision:       $Revision: 29943 $

  Description:    This is a linker command line file for the IAR XLINK tool for the
                  CC2530 SoC and Z-Stack sample applications where the General Options
                  for location for constants and strings is "ROM mapped as data".


  Copyright 2009-2010 Texas Instruments Incorporated. All rights reserved.

  IMPORTANT: Your use of this Software is limited to those specific rights
  granted under the terms of a software license agreement between the user
  who downloaded the software, his/her employer (which must be your employer)
  and Texas Instruments Incorporated (the "License").  You may not use this
  Software unless you agree to abide by the terms of the License. The License
  limits your use, and you acknowledge, that the Software may not be modified,
  copied or distributed unless embedded on a Texas Instruments microcontroller
  or used solely and exclusively in conjunction with a Texas Instruments radio
  frequency transceiver, which is integrated into your product.  Other than for
  the foregoing purpose, you may not use, reproduce, copy, prepare derivative
  works of, modify, distribute, perform, display or sell this Software and/or
  its documentation for any purpose.

  YOU FURTHER ACKNOWLEDGE AND AGREE THAT THE SOFTWARE AND DOCUMENTATION ARE
  PROVIDED �AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESS OR IMPLIED,
  INCLUDING WITHOUT LIMITATION, ANY WARRANTY OF MERCHANTABILITY, TITLE,
  NON-INFRINGEMENT AND FITNESS FOR A PARTICULAR PURPOSE. IN NO EVENT SHALL
  TEXAS INSTRUMENTS OR ITS LICENSORS BE LIABLE OR OBLIGATED UNDER CONTRACT,
  NEGLIGENCE, STRICT LIABILITY, CONTRIBUTION, BREACH OF WARRANTY, OR OTHER
  LEGAL EQUITABLE THEORY ANY DIRECT OR INDIRECT DAMAGES OR EXPENSES
  INCLUDING BUT NOT LIMITED TO ANY INCIDENTAL, SPECIAL, INDIRECT, PUNITIVE
  OR CONSEQUENTIAL DAMAGES, LOST PROFITS OR LOST DATA, COST OF PROCUREMENT
  OF SUBSTITUTE GOODS, TECHNOLOGY, SERVICES, OR ANY CLAIMS BY THIRD PARTIES
  (INCLUDING BUT NOT LIMITED TO ANY DEFENSE THEREOF), OR OTHER SIMILAR COSTS.

  Should you have any questions regarding your right to use this Software,
  contact Texas Instruments Incorporated at www.TI.com.

**************************************************************************************************/

////////////////////////////////////////////////////////////////////////////////
//
//
// Segment limits
// --------------
//
//
// XDATA available to the program.
//
// Reserving address 0x0 for NULL.
-D_XDATA_START=0x0001
-D_XDATA_END=0x1EFF
//
//
// The 8052 IDATA is overlayed on the SoC XDATA space from 0x1F00-0x1FFF.
//
-D_IDATA_END=0xFF              // Last address of Idata memory.
//
//
//    CODE
//
-D_CODE_START=0x0000
-D_CODE_END=0x7FFF             // Last address for ROOT bank.
//
-D_FIRST_BANK_ADDR=0x10000
//
//
//
// Special SFRs
// ------------
//
//    Register bank setup
//
-D?REGISTER_BANK=0             // Default register bank (0,1,2,3).
-D_REGISTER_BANK_START=0       // Start address for default register bank (00,08,10,18).
//
//
//    PDATA page setup
//
-D?PBANK_NUMBER=00             // High byte of 16-bit address to the PDATA area.
//
//
//    Virtual register setup
//    ----------------------
//
-D_BREG_START=0x00             // The bit address where the BREG segments starts.
                               // Must be placed on: _BREG_START%8=0 where _BREG_START <= 0x78.
-D?VB=0x20                     // ?VB is used when referencing BREG as whole byte.
                               // Must be placed on: ?VB=0x20+_BREG_START/8.
//
////////////////////////////////////////////////////////////////////////////////



////////////////////////////////////////////////////////////////////////////////
//
// IDATA memory
//

// Setup "bit" segments (only for '__no_init bool' variables).
-Z(BIT)BREG=_BREG_START
-Z(BIT)BIT_N=0-7F

-Z(DATA)REGISTERS+8=_REGISTER_BANK_START
-Z(DATA)BDATA_Z,BDATA_N,BDATA_I=20-2F
-Z(DATA)VREG+_NR_OF_VIRTUAL_REGISTERS=08-7F
-Z(DATA)PSP,XSP=08-7F
-Z(DATA)DOVERLAY=08-7F
-Z(DATA)DATA_I,DATA_Z,DATA_N=08-7F

-U(IDATA)0-7F=(DATA)0-7F
-Z(IDATA)IDATA_I,IDATA_Z,IDATA_N=08-_IDATA_END
-Z(IDATA)ISTACK+_IDATA_STACK_SIZE#08-_IDATA_END
-Z(IDATA)IOVERLAY=08-FF

////////////////////////////////////////////////////////////////////////////////
//
// ROM memory
//
//
// The following segments *must* be placed in the root bank. The order of
// placement also matters for these segments, which is why we use the -Z
// placement directive.
//
-Z(CODE)INTVEC=_CODE_START
-Z(CODE)BIT_ID,BDATA_ID,DATA_ID,IDATA_ID,IXDATA_ID,PDATA_ID,XDATA_ID=_CODE_START-_CODE_END
//
// Sleep PCON instruction must be 4-byte aligned.
//
-D_SLEEP_CODE_SPACE_START=(_CODE_END-7)
-D_SLEEP_CODE_SPACE_END=(_CODE_END)
-Z(CODE)SLEEP_CODE=_SLEEP_CODE_SPACE_START-_SLEEP_CODE_SPACE_END
//
// The following segments *must* be placed in the root bank, but the order
// of placement within the root bank is not important, which is why we use the
// -P directive here.
//
-P(CODE)CSTART,BANK_RELAYS,RCODE,DIFUNCT,NEAR_CODE=_CODE_START-_CODE_END
//
// Setup for constants located in code memory:
//
-P(CODE)CODE_C=_CODE_START-_CODE_END
//
// Define segments for const data in flash.
// First the segment with addresses as used by the program (flash mapped as XDATA)
-P(CONST)XDATA_ROM_C=0x8000-0xFFFF
//
// Then the segment with addresses as put in the hex file (flash bank 1)
-P(CODE)XDATA_ROM_C_FLASH=0x18000-0x1FFFF
//
// Finally link these segments (XDATA_ROM_C_FLASH is the initializer segment for XDATA_ROM_C,
// we map the flash in the XDATA address range instead of copying the data to RAM)
-QXDATA_ROM_C=XDATA_ROM_C_FLASH
//
// The directive below ensures that the remaining space in the root bank gets
// filled, then starts filling the banks.
//
-P(CODE)BANKED_CODE=_CODE_START-_CODE_END,0x18000-0x1FFFF,0x28000-0x2FFFF,0x38000-0x3FFFF,\
0x48000-0x4FFFF,0x58000-0x5FFFF,0x68000-0x6FFFF,0x78000-0x7F7FF

////////////////////////////////////////////////////////////////////////////////
//
// XDATA memory
//

-Z(XDATA)XSTACK+_XDATA_STACK_SIZE=_XDATA_START-_XDATA_END
-Z(XDATA)XDATA_Z,XDATA_I=_XDATA_START-_XDATA_END
-P(XDATA)XDATA_N=_XDATA_START-_XDATA_END

-cx51

////////////////////////////////////////////////////////////////////////////////
//
// Texas Instruments device specific
// =================================
//
//
// Layout of CODE banks
// -------------------
//
//-D_BANK0_START=0x08000
//-D_BANK0_END=0x0FFFF
//
//-D_BANK1_START=0x18000
//-D_BANK1_END=0x1FFFF
//
//-D_BANK2_START=0x28000
//-D_BANK2_END=0x2FFFF
//
//-D_BANK3_START=0x38000
//-D_BANK3_END=0x3FFFF
//
//-D_BANK4_START=0x48000
//-D_BANK4_END=0x4FFFF
//
//-D_BANK5_START=0x58000
//-D_BANK5_END=0x5FFFF
//
//-D_BANK6_START=0x68000
//-D_BANK6_END=0x6FFFF
//
//-D_BANK7_START=0x78000
//-D_BANK7_END=0x7FFFF
//
//
// Include these two lines when generating a .hex file for banked code model:
-M(CODE)[(_CODEBANK_START+_FIRST_BANK_ADDR)-(_CODEBANK_END+_FIRST_BANK_ADDR)]*\
_NR_OF_BANKS+_FIRST_BANK_ADDR=0x8000
//
//
// Internal flash used for NV address space: reserving 6 pages.
// NV memory segment size must coincide with page declarations in "hal_board_cfg.h" file.
//
-D_ZIGNV_ADDRESS_SPACE_START=(((_NR_OF_BANKS+1)*_FIRST_BANK_ADDR)-0x3800)
-D_ZIGNV_ADDRESS_SPACE_END=(_ZIGNV_ADDRESS_SPACE_START+0x2FFF)
-Z(CODE)ZIGNV_ADDRESS_SPACE=_ZIGNV_ADDRESS_SPACE_START-_ZIGNV_ADDRESS_SPACE_END
//
//
//
// The last available page of flash is reserved for special use as follows
// (addressing from the end of the page down):
//   16 bytes  Lock bits
//    8 bytes  IEEE address space (EUI-64)
//   22 bytes  Device Private Key (21 bytes + 1 byte pad to NV word size)
//   22 bytes  CA Public Key (22 bytes)
//   48 bytes  Implicit Certificate (48 bytes)
// 1932 bytes  Reserved for future Z-Stack use (1932 bytes)
//
-D_LOCK_BITS_ADDRESS_SPACE_START=(((_NR_OF_BANKS+1)*_FIRST_BANK_ADDR)-0x10)
-D_LOCK_BITS_ADDRESS_SPACE_END=(_LOCK_BITS_ADDRESS_SPACE_START+0x0F)
-Z(CODE)LOCK_BITS_ADDRESS_SPACE=_LOCK_BITS_ADDRESS_SPACE_START-_LOCK_BITS_ADDRESS_SPACE_END
//
-D_IEEE_ADDRESS_SPACE_START=(_LOCK_BITS_ADDRESS_SPACE_START-0x08)
-D_IEEE_ADDRESS_SPACE_END=(_IEEE_ADDRESS_SPACE_START+0x07)
-Z(CODE)IEEE_ADDRESS_SPACE=_IEEE_ADDRESS_SPACE_START-_IEEE_ADDRESS_SPACE_END
//
-D_DEV_PRIVATE_KEY_ADDRESS_SPACE_START=(_IEEE_ADDRESS_SPACE_START-0x16)
-D_DEV_PRIVATE_KEY_ADDRESS_SPACE_END=(_DEV_PRIVATE_KEY_ADDRESS_SPACE_START+0x15)
-Z(CODE)DEV_PRIVATE_KEY_ADDRESS_SPACE=_DEV_PRIVATE_KEY_ADDRESS_SPACE_START-_DEV_PRIVATE_KEY_ADDRESS_SPACE_END
//
-D_CA_PUBLIC_KEY_ADDRESS_SPACE_START=(_DEV_PRIVATE_KEY_ADDRESS_SPACE_START-0x16)
-D_CA_PUBLIC_KEY_ADDRESS_SPACE_END=(_CA_PUBLIC_KEY_ADDRESS_SPACE_START+0x15)
-Z(CODE)CA_PUBLIC_KEY_ADDRESS_SPACE=_CA_PUBLIC_KEY_ADDRESS_SPACE_START-_CA_PUBLIC_KEY_ADDRESS_SPACE_END
//
-D_IMPLICIT_CERTIFICATE_ADDRESS_SPACE_START=(_CA_PUBLIC_KEY_ADDRESS_SPACE_START-0x30)
-D_IMPLICIT_CERTIFICATE_ADDRESS_SPACE_END=(_IMPLICIT_CERTIFICATE_ADDRESS_SPACE_START+0x2F)
-Z(CODE)IMPLICIT_CERTIFICATE_ADDRESS_SPACE=_IMPLICIT_CERTIFICATE_ADDRESS_SPACE_START-_IMPLICIT_CERTIFICATE_ADDRESS_SPACE_END
//
-D_RESERVED_ADDRESS_SPACE_START=(_IMPLICIT_CERTIFICATE_ADDRESS_SPACE_START-0x78C)
-D_RESERVED_ADDRESS_SPACE_END=(_RESERVED_ADDRESS_SPACE_START+0x78B)
-Z(CODE)RESERVED_ADDRESS_SPACE=_RESERVED_ADDRESS_SPACE_START-_RESERVED_ADDRESS_SPACE_END
//
////////////////////////////////////////////////////////////////////////////////

A steady supply of 3.3 V is suitable, I am not aware of any significance regarding P1_6 with either the CC-DEBUGGER or Z-Stack application.  Are you using the CC2530 flash Serial Boot Loader?  You should not need to modify FMAP manually as the Z-Stack code should already map all code banks into the upper area of the CODE memory space.  The linker command file does reserve space for the IEEE address:

// The last available page of flash is reserved for special use as follows
// (addressing from the end of the page down):
//   16 bytes  Lock bits
//    8 bytes  IEEE address space (EUI-64)
//   22 bytes  Device Private Key (21 bytes + 1 byte pad to NV word size)
//   22 bytes  CA Public Key (22 bytes)
//   48 bytes  Implicit Certificate (48 bytes)
// 1932 bytes  Reserved for future Z-Stack use (1932 bytes)
//
-D_LOCK_BITS_ADDRESS_SPACE_START=(((_NR_OF_BANKS+1)*_FIRST_BANK_ADDR)-0x10)
-D_LOCK_BITS_ADDRESS_SPACE_END=(_LOCK_BITS_ADDRESS_SPACE_START+0x0F)
-Z(CODE)LOCK_BITS_ADDRESS_SPACE=_LOCK_BITS_ADDRESS_SPACE_START-_LOCK_BITS_ADDRESS_SPACE_END
//
-D_IEEE_ADDRESS_SPACE_START=(_LOCK_BITS_ADDRESS_SPACE_START-0x08)
-D_IEEE_ADDRESS_SPACE_END=(_IEEE_ADDRESS_SPACE_START+0x07)
-Z(CODE)IEEE_ADDRESS_SPACE=_IEEE_ADDRESS_SPACE_START-_IEEE_ADDRESS_SPACE_END

Have you tried to set this value as a constant instead of modifying it at runtime?  please see OnBoard.c and this E2E post as reference: https://e2e.ti.com/support/wireless-connectivity/zigbee-and-thread/f/158/t/146001

Regards,
Ryan

Hi Ryan:

Are you using the CC2530 flash Serial Boot Loader?

---winkeys: No. I did not use the CC2530 flash Serial Boot Loader.

Have you tried to set this value as a constant instead of modifying it at runtime?

---winkeys: yes. Previously, I used to dynamically modify the secondary MAC through ZNP methold at runtime, but the result failed. So later, I used the constant to write the secondary MAC in the main function, but it still failed.

Have you tried replicating this issue with a newer Z-Stack solution, such as Z-Stack HA 1.2.2a (from Z-STACK-ARCHIVE) or Z-Stack 3.0.2?

---winkeys:Today, I got the original ZStack-CC2530-2.5.1a. Based on the SimpleApp.eww project, I added the following lines of code, and the results are the same as before. As follows:
<1>Using ccdebugger, clicking "download and debug" at IAR, my own code can change the secondary MAC successfully this time.
<2>With ccdebugger is plugging, power down and power on the CC2530, and my own code can not change the secondary MAC successfully.

I don't have the demo board of CC2530. I can only test it on my own board. If you have the demo board of CC2530, you can verify it.
And later, I will try it with Z-Stack HA 1.2.2a and Z-Stack 3.0.1, and tell you the results.
I guess when debugging with IAR, IAR will send some code through CC / DD interface to unlock page 127 or other. But we can not operate it ,Is it right?

Operation sequence：

<1>Using ccdebugger, clicking "download and debug" at IAR. -> go -> stop debugging.

<2>using flash programmer to read secondary mac

<3>using flash programmer to "erase", adn then "erase program and verify",download you hex to run.

<4>using flash programmer to read secondary mac

the SimpleApp.eww project location: ZStack-CC2530-2.5.1a\Projects\zstack\Samples\SimpleApp\CC2530DB\SimpleApp.eww
code fragment（The blue part code is added）：
static void zmain_ext_addr(void)
{
uint8 nullAddr[Z_EXTADDR_LEN] = {0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF};
uint8 writeNV = TRUE;

uint8 testMac2[Z_EXTADDR_LEN] = {0x88,0x88,0x88,0x88,0x88,0x88,0x88,0x88};
HalFlashErase(127);
HalFlashWrite(0xFFFA, testMac2, 2);

// First check whether a non-erased extended address exists in the OSAL NV.
if ((SUCCESS != osal_nv_item_init(ZCD_NV_EXTADDR, Z_EXTADDR_LEN, NULL)) ||
(SUCCESS != osal_nv_read(ZCD_NV_EXTADDR, 0, Z_EXTADDR_LEN, aExtendedAddress)) ||
(osal_memcmp(aExtendedAddress, nullAddr, Z_EXTADDR_LEN)))
{
// Attempt to read the extended address from the location on the lock bits page
// where the prog

Hello Winkeys,

I do not currently have a CC2530 to test with.  Please refer to the secondary IEEE MAC address variable reserved inside OnBoard.c:

#pragma location="IEEE_ADDRESS_SPACE"
__no_init uint8 _nvIEEE[Z_EXTADDR_LEN];
#pragma required=_nvIEEE

I recommend you try modifying this value.  Also, your addr parameter for HalFlashWrite is not correct as it should be the actual addr divided by four and quad-aligned.

Regards,
Ryan

Hello Ryan:

I recommend you try modifying this value.

---winkeys:Just now, I tested it with the following blue added code as you recommend, and the results are the same as follows.

<1>Using ccdebugger, clicking "download and debug" at IAR, my own code can change the secondary MAC successfully this time.
<2>using flash programmer to "erase", and then "erase program and verify",download my hex to run. Power off and then power on. Using flash programmer to read secondary mac, and find the secondary MAC not change successfully.

#if defined MAKE_CRC_SHDW
#pragma location="CRC_SHDW"
const CODE uint16 _crcShdw = 0xFFFF;
#pragma required=_crcShdw

#else // if !defined MAKE_CRC_SHDW

#pragma location="LOCK_BITS_ADDRESS_SPACE"
__no_init uint8 _lockBits[16];
#pragma required=_lockBits

#if defined ZCL_KEY_ESTABLISH
#include "zcl_cert_data.c"
#else
#pragma location="IEEE_ADDRESS_SPACE"
//__no_init uint8 _nvIEEE[Z_EXTADDR_LEN];
//const uint8 _nvIEEE[Z_EXTADDR_LEN] = {0x22,0x22,0x22,0x22,0x22,0x22,0x22,0x22};
const uint8 _nvIEEE[Z_EXTADDR_LEN] = {0x33,0x33,0x33,0x33,0x33,0x33,0x33,0x33};
#pragma required=_nvIEEE
#endif

#pragma location="RESERVED_ADDRESS_SPACE"
__no_init uint8 _reserved[1932];
#pragma required=_reserved
#endif

 Also, your addr parameter for HalFlashWrite is not correct as it should be the actual addr divided by four and quad-aligned.

---winkeys: According to the original ZStack-CC2530-2.5.1a,  do you think what exact vlaue of addr parameter for HalFlashWrite should be?

Supplementary:

uint8 testMac2[Z_EXTADDR_LEN] = {0x88,0x88,0x88,0x88,0x88,0x88,0x88,0x88};
HalFlashErase(127);
HalFlashWrite(0xFFFA, testMac2, 2);

The function "HalFlashWrite" prototype is as follows in hal_flash.c :
HalFlashWrite(uint16 addr, uint8 *buf, uint16 cnt)
* @param addr - Valid HAL flash write address: actual addr / 4 and quad-aligned.
* @param buf - Valid buffer space at least as big as 'cnt' X 4.
* @param cnt - Number of 4-byte blocks to write.
so I think the secondary MAC addr =( (HAL_FLASH_IEEE_PAGE * HAL_FLASH_PAGE_SIZE ) + HAL_FLASH_IEEE_OSET )/4
= (127*2048 + 2024)/4
= 0xFFFA

Hi Winkeys,

I made a mistake regarding HalFlashWrite and have modified my previous post accordingly, thank you for following up on this.  Note that as currently designed, the code for _nvIEEE will not be built if ZCL_KEY_ESTABLISH is not defined in the project.  You may consider removing this requirement.  After building the hex image, does the data starting at memory address 0x3FFE8 not contain the intended IEEE address?

Regards,
Ryan

Hello Ryan:

Note that as currently designed, the code for _nvIEEE will not be built if ZCL_KEY_ESTABLISH is not defined in the project.  You may consider removing this requirement.  After building the hex image, does the data starting at memory address 0x3FFE8 not contain the intended IEEE address?

---winkeys:  I did not define ZCL_KEY_ESTABLISH. Based on the code(Onboard.c), I think that the code for _nvIEEE will be built if ZCL_KEY_ESTABLISH is not defined in the project. 

#if defined ZCL_KEY_ESTABLISH
#include "zcl_cert_data.c"
#else
#pragma location="IEEE_ADDRESS_SPACE"
//__no_init uint8 _nvIEEE[Z_EXTADDR_LEN];
//const uint8 _nvIEEE[Z_EXTADDR_LEN] = {0x22,0x22,0x22,0x22,0x22,0x22,0x22,0x22};
const uint8 _nvIEEE[Z_EXTADDR_LEN] = {0x33,0x33,0x33,0x33,0x33,0x33,0x33,0x33};
#pragma required=_nvIEEE
#endif

After building the hex image, does the data starting at memory address 0x3FFE8 not contain the intended IEEE address?

---winkeys: when I did not define ZCL_KEY_ESTABLISH, I could find my intended IEEE address at the end of the hex image at memory address 0x3FFE8 as follows.

                  however, when I defined ZCL_KEY_ESTABLISH, I could not find my intended IEEE address at the end of the hex image at memory address 0x3FFE8.

when const uint8 _nvIEEE[Z_EXTADDR_LEN] =  {0x33,0x33,0x33,0x33,0x33,0x33,0x33,0x33}:

:0CDBF00007EDC082C083E99004EA80EEDB
:020000040003F7
:08FFE800333333333333333379
:0400000500000A34B9
:00000001FF

when const uint8 _nvIEEE[Z_EXTADDR_LEN] = {0x22,0x22,0x22,0x22,0x22,0x22,0x22,0x22}:

:0CDBF00007EDC082C083E99004EA80EEDB
:020000040003F7
:08FFE800222222222222222201
:0400000500000A34B9
:00000001FF

So far, whether I modify the secondary MAC dynamically or statically, the result is the same: debugging with IAR, only this time, is successful, but running without IAR (using flash programmer directly) is not successful. I doubt it:

1> What is the inner difference between action with and without IAR?

2> Is there a hardware pin or command that controls page127?

3> What is the general way for customers you know to modify the secondary MAC? Do you have a reference code?

This problem has been bothering me for a long time. I look forward to your advice.

You are correct regarding ZCL_KEY_ESTABLISH, it has been amended in my prior response.  Based on your findings it appears that the _nvIEEE value is being stored inside the hex image properly and that the IAR programmer flashes this area of memory correctly.  Hence the code appears valid and the issue could be from the operation of FLASH-PROGRAMMER.  Please refer to section 5.1.1.4 of the User Manual (SWRU069): If the “Retain IEEE address when reprogramming the chip” is checked the IEEE address is preserved when a new program is written to the chip with the “Erase and program” or “Erase, program and verify” action. This is however not possible if the debug command lock is set on the chip before the programming starts.

There are no hardware pins which control the last flash page, only the command linker file usage and debug commands.  FLASH_PROGRAMMER is the recommended method of modifying the secondary IEEE address.

Regards,
Ryan