z-stack中Nv条目item ID和flash实际的物理地址之间有什么关系？
在z-stack中，每一个参数的配置对应的是一个Nv条目(item),每一个item都有自己的ID，z-stack中使用的条目ID范围如下：
0x0000 保留
0x0001~0x0020 操作系统抽象层（OSAL）
0x0021~0x0040 网络层（NWK）
0x0041~0x0060 应用程序支持子层（APS）
0x0061~0x0080 安全（Security）
0x0081~0x00A0 Zigbee设备对象（ZDO）
0x00A1~0x0200 保留
0x0201~0x0FFF 应用程序
0x1000~0xFFFF 保留
比如在应用程序中存储一个数据：
unsigned char value_read;
unsigned char value = 0x18;
osal_nv_item_init(0x201,1,NULL);
osal_nv_item_write(0x201,0,1,&value);
osal_nv_item_read(0x201,0,1,&value_read);
但这个数据在整个flash中被存放到哪里了呢？一直都没找到他的实际物理地址。。。
没有任何的关系。我们只规定了NV区域的大小和具体的位置，但是针对条目没办法找到实际的位置。
某个NV Item的操作并不是固定在Flash中某个地址上的，也就是说如果最一个NV Item做两次写操作，这两次写的数据在Flash中是不同的位置。
NV操作的机制，是通过追加的方式来实现的，每次需要写数据的时候写到之前写过的最后面，然后把原先那个标志为废弃，等到废弃的Flash等于一个page的时候，再一次性擦除。
这样做的目的为了保护Flash。
http://www.deyisupport.com/question_answer/wireless_connectivity/zigbee/f/104/t/92984.aspx
在法问题前，可以搜索下别人咨询的问题，谢谢！
非常感谢VV的回答和建议，以后会注意的，您上面说的“NV操作的机制，是通过追加的方式来实现的，每次需要写数据的时候写到之前写过的最后面，然后把原先那个标志为废弃，等到废弃的Flash等于一个page的时候，再一次性擦除。”也就是说用户区的NV应该是保存在Flash上固定的6个page（f8w2530.xcl上面的注释:Internal flash used for NV address space: reserving 6 pages.）上的是吗？，那么那个这6个page具体是page0~page127上的哪6个Page呢？因为目前在研究flash锁保护，想把flash上的程序部分锁死，但是又想保留NV数据能够修改和访问，所以需要知道NV具体在哪个page上
经过计算NV的6个page在flash的具体位置为Page121~Page126，Page127为特殊用途的Page,计算方法如下：
在f8wcc2530.xcl中，有下面两段注释：
// 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
因为已经知道了LockBit的地址为0x7FFF0~0x7FFFF，所以可以计算出(_NR_OF_BANKS+1)*_FIRST_BANK_ADDR = 0x7FFF0 + 0x10
所以ZIGNV_ADDRESS_SPACE_START=(((_NR_OF_BANKS+1)*_FIRST_BANK_ADDR)-0x3800)=0x7C800
所以NV所在的具体地址为0x7C800~0x7F7FF，刚好12KB的空间，也即6Pages，依次对应Page121~Page126
我觉得这样设计也是有原因的，可以确保程序区的完整性，对于cc2530 flash 的存储分配情况，总算是弄清楚了
经过计算NV的6个page在flash的具体位置为Page121~Page126，Page127为特殊用途的Page,计算方法如下：
在f8wcc2530.xcl中，有下面两段注释：
// 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-Stackuse (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
因为已经知道了LockBit的地址为0x7FFF0~0x7FFFF，所以可以计算出(_NR_OF_BANKS+1)*_FIRST_BANK_ADDR = 0x7FFF0 + 0x10
所以ZIGNV_ADDRESS_SPACE_START=(((_NR_OF_BANKS+1)*_FIRST_BANK_ADDR)-0x3800)=0x7C800
所以NV所在的具体地址为0x7C800~0x7F7FF，刚好12KB的空间，也即6Pages，依次对应Page121~Page126
我觉得这样设计也是有原因的，可以确保程序区的完整性，对于cc2530flash 的存储分配情况，总算是弄清楚了