The mac seq number in 802.15.4 Sleepy device

[wslee]

* Test environment : 
 - JN5169 
 - SDK : JN-SW-4163
 - device : Coordinator, Sleepy device
 - JN-AN-1174

I am using  vAppApiSaveMacSettings() before vAHI_Sleep(E_AHI_SLEEP_OSCON_RAMON) and vAppApiRestoreMacSettings() when AppWarmStart().

My problem is the following.

The mac seq number is always same if it transmits by vAppApiMcpsRequest() when sleepy device was woken from sleep mode .

That mac seq is 76.

But When none sleep, it's normally increase by one.

The attachment is sniffer log.

Best Regards,

lee

[mario_castaneda]

Hi Lee,

Please print the pu8Payload[0]  value before you go to sleep. The sEndDeviceData.u8TxPacketSeqNb++ is increasing the sequence number.

Regards,

Mario

[wslee]

Hi Mario,

I am using packets in my format. So, the pu8Payload[0] is always 0xaa.

My question is MAC Sequence.

Regards,

Lee

[wslee]

Hi Mario,

How's it going?

Regards,

Lee

[mario_castaneda]

Hi Lee,

You must modify the MAC_Pib_s structure before sending the data.

    uint8                       u8Dsn;/**< macDSN attribute */
.
.

} MAC_Pib_s; 
mac_pib_CombinedMac.h


s_psMacPib->u8Dsn= count++;‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍

Let me know your findings.

Mario

[wslee]

Hi Mario,

Thanks for your response.

I have tested, but the result is same. This mac seq is always 76.

The following is source code.

PRIVATE void vTransmitDataPacket(uint8 *pu8Data, uint8 u8Len, uint16 u16DestAdr)
{
   MAC_McpsReqRsp_s sMcpsReqRsp;
   MAC_McpsSyncCfm_s sMcpsSyncCfm;
   uint8 *pu8Payload, i = 0;

   PRIVATE u8 count;

   s_pvMac = pvAppApiGetMacHandle();
   s_psMacPib = MAC_psPibGetHandle(s_pvMac);
   s_psMacPib->u8Dsn = count++;

   /* Create frame transmission request */
   sMcpsReqRsp.u8Type = MAC_MCPS_REQ_DATA;
   sMcpsReqRsp.u8ParamLength = sizeof(MAC_McpsReqData_s);
   /* Set handle so we can match confirmation to request */
   sMcpsReqRsp.uParam.sReqData.u8Handle = 1;

   /* Use short address for source */
   sMcpsReqRsp.uParam.sReqData.sFrame.sSrcAddr.u8AddrMode = 2;
   sMcpsReqRsp.uParam.sReqData.sFrame.sSrcAddr.u16PanId = u16panid;
   sMcpsReqRsp.uParam.sReqData.sFrame.sSrcAddr.uAddr.u16Short = u16id;
   /* Use short address for destination */
   sMcpsReqRsp.uParam.sReqData.sFrame.sDstAddr.u8AddrMode = 2;
   sMcpsReqRsp.uParam.sReqData.sFrame.sDstAddr.u16PanId = u16panid;
   sMcpsReqRsp.uParam.sReqData.sFrame.sDstAddr.uAddr.u16Short = u16DestAdr;

   /* Frame requires ack but not security, indirect transmit or GTS */
   sMcpsReqRsp.uParam.sReqData.sFrame.u8TxOptions = 0;//MAC_TX_OPTION_ACK;

   pu8Payload = sMcpsReqRsp.uParam.sReqData.sFrame.au8Sdu;
   for (i = 0; i < (u8Len); i++)
   {
      pu8Payload[i] = *pu8Data++;
   }

   /* Set frame length */
   sMcpsReqRsp.uParam.sReqData.sFrame.u8SduLength = i;

   /* Request transmit */
   vAppApiMcpsRequest(&sMcpsReqRsp, &sMcpsSyncCfm);

}

Regards,

Lee

[mario_castaneda]

Hi Lee,

You should add the code out of the vTransmitDataPacket and before of it.

 s_psMacPib->u8Dsn= count++;

 vTransmitDataPacket(&TxData,9,TagVstemp.u16coordShortAdr);‍‍‍

Please let me know your findings.

Regards,

Mario

[wslee]

Hi Mario,

I don't know the difference between the codes.

Anyway, I have tested, but the result is same.

Does your code work?
Please send me some sample code.

Regards,

Lee

[mario_castaneda]

Hi Lee Wonsoo,

How are you implementing the sleep mode?

 PRIVATE MAC_Pib_s *s_psMacPib;  

 while (1)
    {
        vProcessEventQueues();
        if(sEndDeviceData.eState == E_STATE_ASSOCIATED)
        {
           s_psMacPib->u8Dsn= count++;
           DBG_vPrintf(TRUE,"s_psMacPib->u8Dsn 0%0d;\n",s_psMacPib->u8Dsn);
           vTransmitDataPacket(&TxData,9,TagVstemp.u16coordShortAdr);
       
        }
        if(sEndDeviceData.eState == E_STATE_TX_END)
        {

        }
    }‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍

Regards,

Mario

[wslee]

Hi Mario.

I found the Issues in Makefile.

Before

CFLAGS += -DENABLE_OPT_IN_MAKE
CFLAGS += -DENABLE_OPT_RFD

After

#CFLAGS += -DENABLE_OPT_IN_MAKE 
#CFLAGS += -DENABLE_OPT_RFD 

I have changed for sleepy device but It was the wrong setting.

Thank you for your support.

Regards,

Lee