请问z-stack中Nv条目item ID和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 的存储分配情况，总算是弄清楚了