topic Re: JN5169: MCPS Synchronous Data Confirm in Wireless MCU

JN5169: MCPS Synchronous Data Confirm

ramonet — Thu, 09 Jul 2020 06:51:32 GMT

According to the 2.6 User Guide, it is possible to have Synchronous Data Confirm (i.e. Return the results immediately, rather than the results being posted as a deferred confirm sometime later).

See Section 3.8.3. (User Guide 2.6) or page 18 (stack API v1.7).

Regardless of this description, no explanation is given on how to achieve this. The example JN-AN-1174 only uses deferred confirms.

Here is what I tried, please check what is after vAppApiMcpsRequest.

PRIVATE void vTransmitDataPacket(uint8 *pu8Data, uint8 u8Len, uint16 u16DestAdr)
{
 MAC_McpsReqRsp_s sMcpsReqRsp;
 MAC_McpsSyncCfm_s sMcpsSyncCfm;
 uint8 *pu8Payload, i = 0;
/* 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 = 0;
 /* Use short address for source */
 sMcpsReqRsp.uParam.sReqData.sFrame.sSrcAddr.u8AddrMode = 2;
 sMcpsReqRsp.uParam.sReqData.sFrame.sSrcAddr.u16PanId = PAN_ID;
 sMcpsReqRsp.uParam.sReqData.sFrame.sSrcAddr.uAddr.u16Short = sEndDeviceData.u16Address;
 /* Use short address for destination */
 sMcpsReqRsp.uParam.sReqData.sFrame.sDstAddr.u8AddrMode = 2;
 sMcpsReqRsp.uParam.sReqData.sFrame.sDstAddr.u16PanId = PAN_ID;
 sMcpsReqRsp.uParam.sReqData.sFrame.sDstAddr.uAddr.u16Short = u16DestAdr;
/* Transmit without ack req */
 sMcpsReqRsp.uParam.sReqData.sFrame.u8TxOptions = 0; // for ack req : MAC_TX_OPTION_ACK;
 pu8Payload = sMcpsReqRsp.uParam.sReqData.sFrame.au8Sdu;
pu8Payload [0] = 0x00;
 pu8Payload [1] = 0x01;
 pu8Payload [2] = 0x02;
 pu8Payload [3] = 0x03;
/* Set frame length */
 sMcpsReqRsp.uParam.sReqData.sFrame.u8SduLength = 4;
/* Request transmit */
 uint32 currentTime = vGetMicroSeconds();
 DBG_vPrintf(TRUE,"%d MicroSec | Transmit Request with size %d \n",currentTime,sMcpsReqRsp.uParam.sReqData.sFrame.u8SduLength);
 vAppApiMcpsRequest(&sMcpsReqRsp, &sMcpsSyncCfm);

DBG_vPrintf(TRUE,"syncfmstatus %d \n",sMcpsSyncCfm.u8Status);
//Status  here should be != deferred if we want a sync mcps confirm
 if (sMcpsSyncCfm.u8Status != MAC_MCPS_CFM_DEFERRED){
 if (sMcpsSyncCfm.uParam.sCfmData.u8Status == MAC_ENUM_SUCCESS)
 {
 uint32 time1 = vGetMicroSeconds();
 DBG_vPrintf(TRUE,"%d MicroSec | Sync Data transmit confirm \n",time1);
 }
 }


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

Any way to achieve this synchronous MCPS-DATA.request - confirm?

Any help is much appreciated.

Regards,

Re: JN5169: MCPS Synchronous Data Confirm

mario_castaneda — Tue, 14 Jul 2020 20:00:40 GMT

Hi Alberto,

Please look at the 1.15.2 Blocking and Non-Blocking Operation Chapter, the process that you need is the MAC User and MAC Layer wait for the response or confirm before carrying on processing.

The next chapter will help you with this process.3.4 Synchronisation. We provide an example of a beacon synchronization request 3.5.3 Beacon Examples

The vAppApiMlmeRequest API will help you to achieve this, look at the pointer structure *psMlmeReqRsp. Type MAC_MLME_REQ_SYNC.

Regards,

Mario

Re: JN5169: MCPS Synchronous Data Confirm

ramonet — Wed, 15 Jul 2020 07:48:29 GMT

Hi Mario,

Thank you for taking the time to answer my question.

I think the question was more about whether or not data.request - data.confirm was a blocking operation (Synchronized by the terms used in NXP manual). Which according to the manual its "Return the results immediately, rather than the results being posted as a deferred confirm sometime later".

This is a little unclear because data.confirm is handle by "vHandleMcpsDataDcfrm" , and as far as I know the D stands for Deferred which somehow means this is a non-blocking operation, but in other section of the reference guide its inferred that this is indeed a blocking operation (synchronized) and therefore not "deferred".

This is also somehow related to my other question in https://community.nxp.com/message/1337119

The sync operation used in the beacon mode is unrelated. I was talking about the transmission of data packets in beaconless mode.

Thank you for your time.