CC2630: CC2630: Zstackapi_sysResetReq leads to new IEEE address part2.

Hey,

Thank you for your reply:

we've tried a few things:

using memcpy(user0Cfg.extendedAddress,(uint8_t *)&(__ccfg.CCFG_IEEE_MAC_0), ZSTACKCONFIG_EXT_ADDR_LEN);

= 0xFF FF FF FF -> which makes totally sense, cause we don't programm it.

reading out:

memcpy(user0Cfg.extendedAddress,(uint8_t *)(FCFG1_BASE + EXTADDR_OFFSET), ZSTACKCONFIG_EXT_ADDR_LEN);

copies the IEEE address in user0CFg. which is in our case: 00124B001478AABE (see screenshot)

now the strange parts:

when we erase the chip and start zigbee pairing for the first time then we can see that our node starts with the address 00124B001478AABE  as assumed. (see screenshot below)

when we now (hard)reset the controller we write 00124B001478AABE in the usercfg0, but when we try to join again then the node appears with the adddress: 00008D8F20002DC0.. (see screenshot below)

we do not understand this behaviour..

in our understanding the stack is initialized with the ieee address from the user0cfg right?

is there a specific zigbeestack call where the address can be set?

we just want to set the ieee address from the FCFG1. (the serialprint shows in both cases that the content of usercfg0 is ok).

edit::

maybe whats also interessting:

we've read out the internal flash of the CC2630 after erasing with fresh zstack and application, then after 1st rejoin and then after second rejoin.

between fresh flash and first join we have some changes between 10D00 and 10D8E as well as in 0BD8F and 01E00. 

between 1st join and second join we have some changes at 10D02, 10D08,10D0C, 10D10, 10D2E, and several other addresses, but most interessting: we can find the address 00008D8F20002DC0 which is used at the second join in the flash address 10DC2 and 10DD2 .... so our question is now... why it is using the address from that flash section? what happens in the stack? 

if it's helpfull we can provide you the hexfiles

Hey Daniel,

I apologize as I continuously referred to how the application sets the IEEE extended address, however this is not the same decision as is made by the Z-Stack core. Inside stack_main of osaltasks.c, the primary address from the FCFG1 area is passed along (as pExtAddr) to zmain_ext_addr but is not the first selection. Z-Stack first checks to see if there is a valid entry inside NV memory. On a new image the NV items are empty so the primary address is used. However on restarts the NV memory is now populated and therefore those values are used instead. NV memory is from 0x1D000 to 0x1EFFF so I believe this is the behavior you are noticing. I've attempted to recreate the issue with the SampleSwitch project but have been unable to replicate the faulty NV memory behavior. Philipp mentioned changing configuration and bootloader settings, if you send linker files (cc26xx_app.icf/cc26xx_app.icf) and other relevant changes then we may be able to identify where the issue lies.  I'm also concerned about Philipp's changes to the ccfg.c file as it appears the project is not using the Z-Stack HA 1.2.2a RTOS release version (2.11)

Regards,
Ryan

Hi Ryan,

Thank you for your reply!

ok in my understanding the adress is set the first time, if there was already an connection then the address is used from the nv flash?

i think the memory is corrupted at runtime and then the corrupted address is stored in runtime, but we have to dig deeper in the stack. i've appended you both linkerscripts.

is there a possibility to directly set the address in the stack after a reset? 

i don't think that the bootloader change at the ccfg has an impact, we just changed the pinlevel of the backdoor pin from 1 to 0 .

linkerscripts.zip

is this thread related to our topic:   ?

Hello,

We also inspect the flash of our cc26xx.. it seems that the IEEE Address is stored correctly the first time in the flash:

so reading out is not correct for some reason.?

for our understanding the implementation of storing the address is not needed, or not needed for our usecase.

or are there any cases where this address from the NV is needed?

we'ved modified our code so like the following:

static void zmain_ext_addr( uint8 *pExtAddr )

{  
  osal_memcpy( aExtendedAddress, pExtAddr, 8 );
  // Set the MAC PIB extended address according to results from above.
  (void) ZMacSetReq( MAC_EXTENDED_ADDRESS, aExtendedAddress );
}

so on every startup or reset it uses the address from the FCFG1 as wanted. ( the first few tests worked, (pair with dslk, readattr, bind + reset, automatic reconnect etc.)