CC1110 + SimpliciTI - can't ping in AP to ED direction

Hi,

can you see the ping packets being sent out by the AP to the ED?

If yes, maybe you can try to increase the delay counter in MRFI_ReplyDelay() like this:

void MRFI_ReplyDelay()
{
  BSP_CRITICAL_STATEMENT( sReplyDelayContext = 1 );
  Mrfi_DelayUsecLong( 2*sReplyDelayScalar, 0, Mrfi_CheckSem );
  BSP_CRITICAL_STATEMENT( sKillSem = sReplyDelayContext = 0 );
}

Thanks for immediate answer.
In ED to AP direction I see ping packets as well as reply packets.In AP to ED direction I see only ping packets. Thera are no reply packets from any ED, so I think there are no reason to increase delay.
P.S. I increased delay as you say but it still not received replay.

I have different SMPL_Init() call on opposite sides (AP and ED). On AP side it applied with callback function while on ED side it applied with null argument.
But I can't find part of code which realize ping reply procedure. It seems to be in SMPL_Receive(), isn't it? 

Hi,

when the ED sends out the ping packet, can you put breakpoint in the RX interrupt function of the AP to see whether it at least receive the packet?

http://processors.wiki.ti.com/index.php/SimpliciTI_FAQ#Debugging_RF_Connection

make sure also that it goes to the dispatchFrame() function in nwk_frame.c and finally to nwk_processPing() in nwk_ping.c.

You might also want to decrease the optimization level to be able to debug properly.

Hi,

Konstantin Ovchinnikov said:

I have different SMPL_Init() call on opposite sides (AP and ED). On AP side it applied with callback function while on ED side it applied with null argument.
But I can't find part of code which realize ping reply procedure. It seems to be in SMPL_Receive(), isn't it? 

the callback function doesn't have anything to do with how the SMPL_Ping() receives the reply. See the implementation of nwk_ping() function as follows:

smplStatus_t nwk_ping(linkID_t lid)
{
  connInfo_t  *pCInfo   = nwk_getConnInfo(lid);
  smplStatus_t rc       = SMPL_BAD_PARAM;
  uint8_t      done     = 0;
  uint8_t      repeatIt = 2;
  uint8_t      msg[MAX_PING_APP_FRAME];
  uint8_t      radioState = MRFI_GetRadioState();
  union
  {
    ioctlRawSend_t    send;
    ioctlRawReceive_t recv;
  } ioctl_info;

  if (!pCInfo || (SMPL_LINKID_USER_UUD == lid))
  {
    /* either link ID bogus or tried to ping the unconnected user datagram link ID. */
    return rc;
  }

  do
  {
#if defined(FREQUENCY_AGILITY) && !defined(ACCESS_POINT)
    uint8_t     i, numChan;
    freqEntry_t channels[NWK_FREQ_TBL_SIZE];

    if (repeatIt == 2)
    {
      /* If FA enabled, first time through set up so that the 'for'
       * loop checks the current channel. This saves time (no scan)
       * and is very likely to succeed. Populate the proper strucure.
       */
      SMPL_Ioctl(IOCTL_OBJ_FREQ, IOCTL_ACT_GET, channels);
      numChan = 1;
    }
    else
    {
      /* If we get here we must scan for the channel we're now on */
      if (!(numChan=nwk_scanForChannels(channels)))
      {
        return SMPL_NO_CHANNEL;
      }
    }
    /* Either we scan next time through or we're done */
    repeatIt--;

    /* this loop Pings on each channel (probably only 1) looking
     * for peer.
     */
    for (i=0; i<numChan && !done; ++i)
    {
      nwk_setChannel(&channels[i]);
#else
    {
      repeatIt = 0;
#endif  /* defined(FREQUENCY_AGILITY) && !defined(ACCESS_POINT) */

      ioctl_info.send.addr = (addr_t *)pCInfo->peerAddr;
      ioctl_info.send.msg  = msg;
      ioctl_info.send.len  = sizeof(msg);
      ioctl_info.send.port = SMPL_PORT_PING;

      /* fill in msg */
      msg[PB_REQ_OS] = PING_REQ_PING;
      msg[PB_TID_OS] = sTid;

      SMPL_Ioctl(IOCTL_OBJ_RAW_IO, IOCTL_ACT_WRITE, &ioctl_info.send);

      ioctl_info.recv.port = SMPL_PORT_PING;
      ioctl_info.recv.msg  = msg;
      ioctl_info.recv.addr = 0;

      NWK_CHECK_FOR_SETRX(radioState);
      NWK_REPLY_DELAY();
      NWK_CHECK_FOR_RESTORE_STATE(radioState);

      if (SMPL_SUCCESS == SMPL_Ioctl(IOCTL_OBJ_RAW_IO, IOCTL_ACT_READ, &ioctl_info.recv))
      {
        repeatIt = 0;
        done     = 1;
        sTid++;   /* guard against duplicates */
      }
    }
  } while (repeatIt);

  return done ? SMPL_SUCCESS : SMPL_TIMEOUT;

}

as can be seen above, at the end of the function, it tries to read out directly the ping reply using the SMPL_Ioctl(IOCTL_OBJ_RAW_IO, IOCTL_ACT_READ, &ioctl_info.recv))

So I was not able ping ED from AP. Is it able generally?

And I have another trouble with SimplisiTI.
As I understand "AP as data hub" configuration allow to organize bi-directional link, and there are
possibility to send data not only from ED to AP, but opposite direction also.
So I change from SMPL_Init(0)  to SMPL_Init(sCB) at ED side and organized process incoming messages through
sCB call back function.
I receive message from AP at ED side, but there are in sniffer I see strange "Management" packets continuously
sending from ED.

Excuse me. Did you solve the this problem?