espressif/openthread
1
0
Fork 0
mirror of https://github.com/espressif/openthread.git synced 2026-08-12 05:37:46 +00:00
Code Issues Packages Projects Releases Wiki Activity

[CC2538]: Fix MAC address word ordering. (#2714)

Browse Source 
It seems TI (for whatever reason) chose to use a rather unorthadox
mixed-endian representation for the MAC address in the CC2538, where the
most significant 4 octets are given first in little-endian order,
followed by the least significant 4 octets (again in little-endian).

The OpenThread code expects a big-endian representation of the MAC, so
we need to read in and byte-swap each half individually.
This commit is contained in:
Stuart Longland
2018-05-23 00:32:34 -07:00
committed by Jonathan Hui
parent 52644515a6
commit 70c3f11741
1 changed files with 21 additions and 3 deletions
Download Patch File Download Diff File Expand all files Collapse all files
examples/platforms/cc2538/radio.c
+21 -3
View File
@@ -189,12 +189,30 @@ void setTxPower(int8_t aTxPower)
void otPlatRadioGetIeeeEui64(otInstance *aInstance, uint8_t *aIeeeEui64)
{
uint8_t *eui64 = (uint8_t *)IEEE_EUI64;
// EUI64 is in a mixed-endian format. Split in two halves, each 32-bit
// half is in little-endian format (machine endian). However, the
// most significant part of the EUI64 comes first, so we can't cheat
// with a uint64_t!
//
// See https://e2e.ti.com/support/wireless_connectivity/low_power_rf_tools/f/155/p/307344/1072252
volatile uint32_t *eui64 = &HWREG(IEEE_EUI64);
(void)aInstance;
for (uint8_t i = 0; i < OT_EXT_ADDRESS_SIZE; i++)
// Read first 32-bits
uint32_t part = eui64[0];
for (uint8_t i = 0; i < (OT_EXT_ADDRESS_SIZE / 2); i++)
{
aIeeeEui64[i] = eui64[7 - i];
aIeeeEui64[3 - i] = part;
part >>= 8;
}
// Read the last 32-bits
part = eui64[1];
for (uint8_t i = 0; i < (OT_EXT_ADDRESS_SIZE / 2); i++)
{
aIeeeEui64[7 - i] = part;
part >>= 8;
}
}