• State
  • Locked Locked
  • Replies 2 replies
  • Subscribers 55 subscribers
  • Views 1263 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Forcing IAR to use the CC2530 primary IEEE identifier in Z-Stack

Brian Degnan
Prodigy 20 points
Other Parts Discussed in Thread: Z-STACK, CC2530

Greetings.

I am having trouble with the CC2530, IAR and Z-Stack.

I would like to force a the use of the "Primary IEEE" identifier in Z-Stack.  I wish to do this because I have found that when I compile the code in IAR and then put it on multiple boards, the MAC address is always the same.  I am sure that it is due to the following from the "Z-Stack User's Guide - CC2530DB.pdf", section 7.2:

 

<verbatum>

Every ZigBee device requires a unique 64-bit IEEE address. Z-Stack uses the following four-level hierarchy to determine the IEEE address that will be used for the device when it operates: 

1) Read from Z-Stack non-volatile memory 

2) Look-up from Secondary IEEE location 

3) Look-up from Primary IEEE location 

4) Create temporary using random number generation 

Under normal circumstances, when a Z-Stack device boots up, it reads the IEEE address from non-volatile memory (NV) that was stored during a previous “run” of the device. NV memory retains parameters, including the IEEE address, for occasions when the device resets, typically after a power failure. The IEEE address in NV memory gets saved under 3 possible scenarios – initially from steps 2-3 of the hierarchy listed above, or later by delivery from an external source (such as via serial I/O from a PC-hosted program like Z-Tool). 

</verbatum>

 

The above leads me to believe that MAC was coded upon compile, and is then always being read.  This is the behavior is see and I have confirmed this behavior across 10 boards where I can successfully read the IEEE primary address in the TI programmer, so it is just being ignored as when I snoop the devices they all have the same MAC address.  If I compile the program each time and program the board though the IAR debugger, I see the MAC boardcast to be the Primary IEEE that I see in the TI programmer.  I have attempted to the "retain IEEE address" option in the TI programmer, but at this point am not interested in the elegant solution as I've exhausted my resources.  I was hoping that there would be a compile option to force the use of the IEEE primary address, but I was unable to find it.  The "Z-Stack Compile Options.pdf" lists compile options but most are not described by the "Z-Stack Developer's Guild.pdf" as specified by "Z-Stack Compile Options.pdf".

 

In summary, I wish to force only using the "Primary IEEE location" for the MAC in Z-Stack using the IAR compiler. 

Any help would be greatly appreciated.

 

--bpd

 

  • 0
    TI__Mastermind 19575 points

    BPD:

    Primary IEEE address should be selected by default. Each CC2530 is preprogrammed with a primary IEEE address and this is stored in the information page.

    Are you not seeing this when you are testing? Have you verified that your Primary IEEE address is transmitted OTA during association (joining) a ZigBee network?

    LPRF Rocks the World 

  • 0 in reply to Morten Braathen
    Prodigy 20 points

    The use of the Primary IEEE address is not the behavior that we have been seeing through the packet sniffer.  I tracked the issue down to a compiler action where the primary address of whichever board that we were using during development was being hard-coded in assembly by IAR.  I can see the address in the .lst file.  The behavior is repeatable in the compiler for our current source code, and in the Zigbee devices that we programmed (we programmed 10 before we found that problem).  I still have no idea how this code is getting into the compiled binary.  So no, I was unable to duplicated the behavior described by the documentation; however, the documentation does match the behavior seen in the source code, but the compiler just had other ideas.  The problem has been resolved by modifying the Z-Stack code; I hate to do things like this, but deadlines are cruel masters.

    I addressed the issue by modifying the "static void zmain_ext_addr(void)" function in ZMain.c to just directly check the secondary IEEE address, primary, and then random by skipping the first step.

    In the simplest form, the function to just use the primary IEEE address could be:

    static void zmain_ext_addr(void){

      uint8 nullAddr[Z_EXTADDR_LEN] = {0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF};

      uint8 writeNV = TRUE;

      osal_memcpy(aExtendedAddress, (uint8 *)(P_INFOPAGE+HAL_INFOP_IEEE_OSET), Z_EXTADDR_LEN);

      (void)ZMacSetReq(MAC_EXTENDED_ADDRESS, aExtendedAddress);

    }

    However, I included the whole address check for steps 2, 3 and 4. Now everything is working great.  As we had not seen this behavior before, I will chalk it up to a one-off compiler error.  Perhaps in the future there will be some DEFINE statements to force this behavior.  I would hate to do a remote programming of a board and have a MAC conflict.

    Thank you for your response.  I will update this thread if this interesting behavior returns in the future.

    --bpd