CC111x and problems linking/communicating to AP (it stops responding)

Hello,

I understand I am asking questions during vacancy time. Nevertheless, I hope I will get at least some feedback anyway.

What I have learned until now is that:

• I should disable joining/linking on AP before programatically enabling UART communication with our custom PC software, since the AP will probably freeze if RF communication starts before UART is running and exchanging data
   
• SMPL_Unlink() should not be called from EDs that can't ping the AP because in such a case, the AP is probably down (I know this should not happen, but in worst case it may and I need robustness) and it's best to unlink EDs using SMPL_Ioctl(IOCTL_OBJ_CONNOBJ, IOCTL_ACT_DELETE, &linkid) and then rejoin when AP returns
   
• If I delete a Link ID on AP using IOCTL_ACT_DELETE and I am not deleting the one that was allocated last, will the released LinkID be reused for the first ED that will link and then will the sPersistInfo.nextLinkID be set to the first unused LinkID value (i.e. equivalent to sNumConnectedPeers)? If not, can I manually assign LinkID's based on my own connection table where I see which linkIDs are active and which free? This disturbs me a lot. :)
  
  
• The only RX-polling ED I have is still causing trouble to the AP:
  - sometimes the ping response to the AP is not successful (the TX-only EDs don't have this problem), such indeterminism causes application problems,
  - if I disable the RX polling the ping response is a bit (but not much) better so I believe I don't poll correctly? What I do is basically:
  
  if (uint8_times++ == 0)
  { 
    SMPL_Ioctl(IOCTL_OBJ_RADIO, IOCTL_ACT_RADIO_RXON, 0);
    SMPL_Receive(linkID, buffer, &len);
    //processing what's received in the buffer
    SMPL_Ioctl(IOCTL_OBJ_RADIO, IOCTL_ACT_RADIO_RXIDLE);
  }
  
  Therefore, I limit the RX polls (uint8_times @ overflow) and I put the radio into RX only when receiving. I also tried without these two SMPL_Ioctl() calls but there is no difference.

Can anyone suggest what in the RX-polling ED may cause the AP to freeze etc.?

Thanks for the help and Best regards,
D11 

The delete question is a very important one-- I'm trying to figure that out myself, as calling the unlink function doesn't seem to be removing the device from the connection table if it relinks. When I cam SMPL_Link trying to relink it, I never get a success, but the device DOES get relinked.

I figured out a few things...

If you want to relink an ED to a ''lost'' accesspoint:
- lost AP is determined by not receiving SMPL_SUCCESS from SMPL_Ping()
- SMPL_Unlink must not be called from the ED since a new LinkID will be allocated upon reconnecting to the AP (we want to reuse the existing LinkID on AP)
- SMPL_Ioctl(IOCTL_OBJ_CONNOBJ, IOCTL_ACT_DELETE, &linkID) has to be called from ED
- Finally, SMPL_Init() and SMPL_Link() are called to reconnect
- In the AP, we are running our own application-layer connection table which helps us mapping addresses to LinkIDs in our own way, so we know which address is having which LinkID (even when relinking) 

When AP has problems transceiving messages: 
- play with out/in queue sizes in nwk_config.dat a little to find best values... 
- don't transceive when in-between USB/CDC communication

When end-devices kill the AP:
- verify that SMPL_Init is immediately followed by SMPL_Link (and don't be smart and put SMPL_Link into a new state of a statemachine, like us, since the linking won't occur)
 

We have managed to solve all our issues, described in the previous posts and now our system works flawlessly. 

Although I was really hoping that I could get some help from TI, but I guess it's vacancy time. Nevertheless, I have heard rumors that at NI's support centre in Budapest each forum thread is assigned to a certain employee and 97% of all threads need to be solved. If something similar is happening at TI, I guess I am in the lucky 3% ? :)

Best regards,
D11 

PS: I am just kidding a bit... 

D11-

I actually ended up solving my problems too. We're doing something completely different, but it looks to be working perfectly. I'm a huge fan of the NVOBJECT functions for saving the stack between power cycles.

I guess that I'm still in the 97% then-- Most of my questions seem to end up with a TI employee...or Jens, if you've seen Jens around!

-Josh

Hi D11,

thanks for sharing your experience here, i think this will be very valuable for the others for sure.

D11 said:

If you want to relink an ED to a ''lost'' accesspoint:

- lost AP is determined by not receiving SMPL_SUCCESS from SMPL_Ping()
- SMPL_Unlink must not be called from the ED since a new LinkID will be allocated upon reconnecting to the AP (we want to reuse the existing LinkID on AP)
- SMPL_Ioctl(IOCTL_OBJ_CONNOBJ, IOCTL_ACT_DELETE, &linkID) has to be called from ED

I am not sure whether the third step here with the SMPL_Ioctl() function is really necessary here after calling the SMPL_Unlink, since the for the local node, i think the affect should be the same. Both functions will basically call the same nwk_freeConnection().

Have you tried to only do SMPL_Unlink()?

D11 said:

When end-devices kill the AP:

- verify that SMPL_Init is immediately followed by SMPL_Link (and don't be smart and put SMPL_Link into a new state of a statemachine, like us, since the linking won't occur)

I am not sure whether i understand what you meant with "killing the AP" here, and how the mentioned steps will solve the problem. Could you explain this more?

Leo-

I've noticed that if you want to remove a device completely, you need to use the SMPL_Ioctl(DELETE). Just unlinking will free the connection, but the same device will still relink without user intervention unless the connection table entry is removed. I'd love to know if I'm missing something here, though.

-Josh E

Josh,

i am not sure about this, i need to check this out with testing on the real hardware. However as i mentioned before, from the code perspective i don't see any difference between SMPL_Unlink() and SMPL_Ioctl(DELETE) since both will basically call nwk_freeConnection().

Joshua Einstein said:

Just unlinking will free the connection, but the same device will still relink without user intervention unless the connection table entry is removed. 

I am not sure whether i understand this problem here. Do you mean the local device will still link to the remote device? Can you please explain this more detail?

Lhend-

It look like you are correct! That's interesting.... What I was seeing was that if I used SMPL_Unlink instead of the SMPL_Ioctl for a specific device, when running my code to relink the device, it was linking automatically without reporting SMPL_SUCCESS in the SMPL_Link. It seemed very odd, but I should probably put this down to something in my code instead of SimpliciTI. I haven't had time to do in depth debugging on this problem as it is working now.

-Josh E

Hello everyone,

Leo- I think you misread what I had written; I actually DO NOT call SMPL_Unlink() on the EDs, because doing so would allocate a new LinkID on the AP after reconnecting (I want to keep the existing LinkID). Therefore, I am doing an IOCTL_ACT_DELETE on EDs before relinking, and it works.

Killing the AP means that the AP gets stuck in some loop and can't break it. Currently, I do not remember which part of SimpliciTI the program counter gets stuck in, but I remember certainly that an ED must after calling SMPL_Init() immediately call SMPL_Link(), else the AP gets killed (i.e. its PC gets stuck in some SimpliciTI loop). It is probably related to some software-based timer I am not using (I commented the BSP_Init() call since I manage the boards myself) and some delay function that would normally break the waiting is probably misfunctioning.

The difference between SMPL_Unlink() and an IOCTL_ACT_DELETE call you were discussing about... if I understand correctly, SMPL_Unlink() sends from AP or ED a frame to break the link apart to an ED or AP, respectively. If one of them is down, such a transmission fails. Performing an IOCTL_ACT_DELETE command proved out to be more robust in our setup.

Best regards,
D11