LP-EM-CC1312PSIP: Access Denied using TI-15.4 stack

Hi Kevin

Can you please be a bit more spesific when describing your issue?

When/where are you getting this message? 

What SDK are you using?

Siri

This is a protocol issue with TI.15.4.  I am using CCS with SimpleLink v7.10.2.23 and the ti154stack.  It happens when the sensor/connector is connected up and I turn off the connector and try to get it to reconnect.  I wanted to know what the condition is that causes an access denied in the protocol and what may allow me to fix it.

Hello Kevin,

May I kindly ask you to check whether the behavior you are experiencing is similar to the one described in this thread? Can you check if the suggested approaches help?

Best regards,

Hi Kevin,

By default the collector project is not configured to re-start the network after being reset.  Thus the sensor cannot rejoin the network and continue sending data until the collector "re-forms" the network by pressing BTN-1 on the collector LaunchPad or selecting NETWORK ACTION -> FORM NWK on the collector's UART UI.  You can change this behavior by defining AUTO_START in your collector's pre-defined compiler settings, this is further described in the collector README.  

I used the default collector/sensor settings when providing this information, so if your configuration is different or I am not describing the correct scenario then please provide more information so that we may be able to further assist you.

Regards,
Ryan

No, while it looked promising, I do close the ports before I flash as they can compete with the XDS110 programming the boards.  Interesting that he was seeing that error message about access denied.

I have AUTO_START enabled as I do want to have it reconnect after loss of signal.  I also pull the status of the radio connection and it shows rejoined even though it isn't connected.  This is usually due to the access denied where it thinks it should be connected, but it isn't.

Thanks for the information Kevin.  Please describe the exact procedure so that we may replicate the issue, determine the root cause, and discuss possible workarounds.  List any changes you've made to the default sensor/collector projects, and providing a sniffer log of the erroneous behavior would certainly be helpful for debugging.

Regards,
Ryan

I have the standard sensor and collector TI15.4 protocol implemented on custom hardware.  I have written code to allow clearing the memory and doing a network new and open as the buttons on the collector allow.  On the sensor side I have implemented the associate to establish the connection.  When I have an established connection and want to reestablish the connection, I clear the memory on the connector and tell it to start a network and open the network.  I then have the sensor side do an associate to start the connection and I receive an accessDenied.  I am thinking since the collector clears the memory of the network before starting the board/protocol that maybe I need a way to restart it too.

Ryan,

I thought that I did that by using the function to clear the keys, but I am afraid that the old keys may still be cached since normally we remove them before the protocol starts by pressing the right key upon powerup.  Is there a way to restart the protocol for it to recognize the keys are removed?

Kevin

Hi Kevin,

Thanks for the update.

I'm Ryan's colleague and will maintain his threads while he is out of office.

Kevin Halberg said:

I am thinking since the collector clears the memory of the network before starting the board/protocol that maybe I need a way to restart it too.

Can you do this on the sensor side too?

Thanks,
Toby

Toby,

Yes, I clear both as part of a pairing process to establish two boards.  However, since the network may need restarted after I don't think I am getting the full effect of it.  I will also try to stop and start the network even though I have the AUTO_START enabled as it may do the trick.  If you have any other suggestions to reset the protocol, I would appreciate knowing about them.

Kevin

I have been looking into this more since I have the packet sniffer working (except for decoding packets).  It am attaching the Wireshark trace when this happens (near the end).  I am trying to sync up the remote with the collector and get accessDenied.  I am thinking this may be happening more from the collector side.  I clear memory on both units, but I don't know if there is more of a reset I need to do.  I think maybe the collector has the wrong address for the sensor when it tries to reconnect.  I know when I disassociate from the collector and then do an associate it bumps the address by one.  I am thinking that this may be connected in such a way that when I try to reconnect it has a mismatch.  Please look at the trace and see if you can tell.  The error is Association response, Unsuccessful. 

Thanks,
Kevin

WRB-WRT accessDenied.zip

Thanks for the sniffer log.  Does this issue only occur when the Collector begins the disassociate process?  cllcDeviceJoiningCB -> Csf_deviceUpdate will return ApiMac_assocStatus_panAtCapacity (0x01) when addDeviceListItem returns false, which you could further debug to determine if this is the case.  However, my evaluation of the default F2 SDK v7.40 examples is not resulting in similar behavior, as disassociations instigated from either the Collector or Sensor can successfully re-associate afterwards.

disassociate_test.pcapng

Regards,
Ryan

I am getting the ApiMac_assocStatus_panAtCapacity (0x01) when I it shows accessDenied.  I have the collector set for only one association and I don't want it to allow over one.  I was able to get this message by clearing the memory on the collector and doing an open network to allow the sensor to connect.  The sensor memory was also cleared.  I need to be able to reassociate a collector and sensor or to associate a new sensor to a collector.  

What is causing the panAtCapacity and how do I fix it?

Kevin