TI中文支持网Part Number:CC2640R2FOther Parts Discussed in Thread:SIMPLELINK-CC2640R2-SDK, CC2650,
使用EasyLink_getIeeeAddr获取IEEE地址时，返回的值为是0xFFFFFFFFFFFFFFFF，而且多块板子都是这个值，为什么？
难道EasyLink_getIeeeAddr不能获取IEEE地址？
如何解决？望帮助，谢谢！
Katherine Wang：
已为您咨询TI工程师，一旦得到回复回立刻回复给您
,
Katherine Wang：
您使用的是哪个版本的 SIMPLELINK-CC2640R2-SDK？ EasyLink 应该使用位于 FCFG1 ROM 存储器中的主要 IEEE 地址（用户不能更改），该地址由 TI 工厂在生产期间配置。这仅适用于您未在 CCFG 内提供辅助 IEEE 地址（通过从该位置读取所有 0xFF 来确定）的情况。您可以一步调试 EasyLink.c 以确定发生了什么故障。
//Primary IEEE address location #define EASYLINK_PRIMARY_IEEE_ADDR_LOCATION(FCFG1_BASE + FCFG1_O_MAC_15_4_0) //Secondary IEEE address location #define EASYLINK_SECONDARY_IEEE_ADDR_LOCATION (CCFG_BASE+ CCFG_O_IEEE_MAC_0)//...EasyLink_Status EasyLink_getIeeeAddr(uint8_t *ieeeAddr) {EasyLink_Status status = EasyLink_Status_Param_Error;if (ieeeAddr != NULL){int i;//Reading from primary IEEE location...uint8_t *location = (uint8_t *)EASYLINK_PRIMARY_IEEE_ADDR_LOCATION;/** ...unless we can find a byte != 0xFF in secondary** Intentionally checking all 8 bytes here instead of len, because we* are checking validity of the entire IEEE address irrespective of the* actual number of bytes the caller wants to copy over.*/for (i = 0; i < 8; i++) {if (((uint8_t *)EASYLINK_SECONDARY_IEEE_ADDR_LOCATION)[i] != 0xFF) {//A byte in the secondary location is not 0xFF. Use the//secondarylocation = (uint8_t *)EASYLINK_SECONDARY_IEEE_ADDR_LOCATION;break;}}//inverting byte orderfor (i = 0; i < 8; i++) {ieeeAddr[i] = location[8 - 1 - i];}status = EasyLink_Status_Success;}return status; }
,
0574119：
首先谢谢你的回复。
情况如下：
1、simplelink_cc2640r2_sdk_4_20_00_04、simplelink_cc2640r2_sdk_3_20_00_21 都用过，结果都是0xFFFFFFFFFFFFFFFF；
2、你给出的代码是EasyLink.c中的函数部分，这些代码我们单步运行过， ieeeAddr[i]都是0xFF。建议你们帮忙实际测试一下试试看？
,
Katherine Wang：
已将您的疑问转达至TI工程师，稍后给您回复
,
Katherine Wang：
此行为是 CC2640R2F 不支持 IEEE MAC/PHY 的结果，因此 IEEE MAC 地址在生产期间未编程到 FCFG，CC2650 等设备会观察到有效地址。您可以使用 BLE MAC 地址在 CC2640R2F 上获得唯一地址，即将 EASYLINK_PRIMARY_IEEE_ADDR_LOCATION 更改为引用 FCFG1_O_MAC_BLE_0 而不是 FCFG1_O_MAC_15_4_0。同样，EASYLINK_SECONDARY_IEEE_ADDR_LOCATION 应改为 CCFG_O_IEEE_BLE_0 而不是 CCFG_O_IEEE_MAC_0。
