• State
  • Locked Locked
  • Replies 1 reply
  • Subscribers 56 subscribers
  • Views 725 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.

TIMAC 1.3.1 BUG with Device Association Process

Kevin Christie
Prodigy 240 points

Other Parts Discussed in Thread: TIMAC

If the following is not actually a bug, I apologize.  With the lack of response I typically get in this forum, I was hoping the subject line would attract more attention.

I am using TIMAC 1.3.1 with IAR 7.6.  I have a cluster tree topology and am currently improving the association process by allowing multiple devices to accurately attempt to join the PAN without short addresses being tosses out the TX buffer at will.

After the association process is complete (MAC_MlmeAssociateRsp sent and device sent a DATA REQUEST), the MAC_MLME_COMM_STATUS_IND section is called.  The data contained in the comm status struct contains source and destination short+ext addresses.  However, the destination short address is not correct, it is simply the last 2 bytes of the extended address.

What I want to do is add a new device to my device list at the completion of the association process (success at MAC_MLME_COMM_STATUS_IND).  I need to know the short and long address during this callback from MAC.  the closest I can get due to TIMAC being a library is MAC_INTERNAL_API void macTxFrame(uint8 txType).  I can see the association rsp about to be sent(which is after the device sent a DATA REQUEST), but that is not good enough, I want this same information after it has been acknowledged.  If multiple associations are happening it is essential to differentiate between them. 

I can put a band-aid on this using more of RAM to store association responses, but I have already filled 7k of my 8k of RAM so I would rather not do that.

Any ideas would be appreciated.

  • 0
    TI__Mastermind 19575 points

    Kevin:

    Below are some ideas:
    My recommendation would be to setup an association device table of the device you would like to have join the network on the coordinator side as possible simple test,

    static NwkDevice_t device[NWK_MAX_NODES]= {
        { 0,0,0,0,0,0,0,0, 0x1971,    0,0, FALSE},    // Device ID 1
        { 0,0,0,0,0,0,0,0, 0x1972,    0,0, FALSE},    // Device ID 2
        { 0,0,0,0,0,0,0,0, 0x1973,    0,0, FALSE},    // Device ID 3
        { 0,0,0,0,0,0,0,0, 0x1974,    0,0, FALSE},    // Device ID 4
        { 0,0,0,0,0,0,0,0, 0x1975,    0,0, FALSE},    // Device ID 5
        { 0,0,0,0,0,0,0,0, 0x1976,    0,0, FALSE},    // Device ID 6
        { 0,0,0,0,0,0,0,0, 0x1978,    0,0, FALSE},    // Device ID 7
        { 0,0,0,0,0,0,0,0, 0x1979,    0,0, FALSE},    // Device ID 8

    // Device descriptor
    typedef struct {
          uint8   extAddr[8];     // IEEE address
          uint16  shortAddr;      // 16-bit address
          uint8   bCAP;           // Capability information
          uint8   nSeq;           // Sequence
          bool    fAckPending; // Waiting for ACK/NAK.
          bool    fLinkUp;  // Link up
    } NwkDevice_t;

    It is also a good idea to make a struct descriptor for your panInfo

    // Device table
    NwkPanInfo_t  panInfoC =
    {
        PANID,                  // PAN identifier
        0,                      // Number of devices
        NWK_START_CHANNEL,      // Channel at start-up
        0,                      // Device ID of last orphaned node
        // MAC-address     ShortAddr  Cap/seqNo
        { 0,0,0,0,0,0,0,0, 0x1111,    0,0},    // Coordinator
        &device[0],
    };

    // PAN descriptor
    typedef struct {
        uint16 panID;           // PAN identifier
        uint8  nDev;            // Number of associated devices
        uint8  iChannel;
        uint8  iOrphanID;       // Device ID of last orphaned node
        NwkDevice_t coord;        // Coordinator
        NwkDevice_t *pDevTable;   // Pointer to device table
    } NwkPanInfo_t;

    Here is an example for a nwk Device association function:

    #define SHORT_ADDR_NONE  0xFFFF
    uint8 nwkDeviceAttach(void)
    {
     uint8 ret;

     // Initialise device block
     device.shortAddr= SHORT_ADDR_NONE;
     nwkMacGetExtAddress((uint8*)&device.extAddr);

     ret= nwkMacAssociate(NWK_ASSOCIATION_TIMEOUT);

        return ret;
    }

    uint8 nwkMacAssociate(uint16 iTimeout)
    {
      macPanDesc_t *pPanDescriptor;
      uint8 bBeaconOrder;

      // Get PAN info
      pPanDescriptor= nwkGetPanDescriptor(DEFAULT_PAN_DESCR_ID);
      if (pPanDescriptor==NULL)
        return NWK_NO_PAN;           // Failed to detect PAN

      if(pPanDescriptor->coordPanId == af_PanId){
        panInfoD.panID=       pPanDescriptor->coordPanId;
      } else {
        return NWK_PAN_MISMATCH;
      }

      panInfoD.coord.shortAddr= pPanDescriptor->coordAddress.addr.shortAddr;
      bBeaconOrder= MAC_SFS_BEACON_ORDER(pPanDescriptor->superframeSpec);

      MAC_MlmeSetReq(MAC_EXTENDED_ADDRESS, &af_ExtAddr);

      /* Setup PAN ID */
      MAC_MlmeSetReq(MAC_PAN_ID, &af_PanId);

      /* Setup Beacon Order */
      MAC_MlmeSetReq(MAC_BEACON_ORDER, &bBeaconOrder);

      /* This device is setup for Direct Message */
      if (af_IsDirectMsg)
        MAC_MlmeSetReq(MAC_RX_ON_WHEN_IDLE, &af_MACTrue);
      else
        MAC_MlmeSetReq(MAC_RX_ON_WHEN_IDLE, &af_MACFalse);

      /* Setup Coordinator short address */
      MAC_MlmeSetReq(MAC_COORD_SHORT_ADDRESS, &msa_AssociateReq.coordAddress.addr.shortAddr);

      MAC_MlmeAssociateReq(&msa_AssociateReq);
      return NWK_OK;
    }

    LPRF Rocks the World