differences-nxp-ti.md

@@ -2,5 +2,7 @@ This page explains the main differences to keep in mind between the Texas Instru
 
 The first one is that lots of packets in ZStack are sent as synchronous packets receiving immediately a sort of acknowledgment from the dongle and then, for packets that need to pass through the zigbee network and receive a response from the remote device, it send asynchronously a packet that contains that response. Often the first is indicated with SRSP while the second RSP. The BeeStack, instead, does not send the synchronous response: it just take the command, send it through the network, wait for the response and send a callback containing the status of success.
 
-To complain with the ZStack, the library contains a function called waitAndLock3WayConversation, where 3Way means the request, the synchronous response and the callback. That function uses a map to avoid that more request of the same type are sent so that the system doesn't know which request the response is for. Actually the function never checks that the conversation is performed that way, so it could be used also for the message exchange as it is done through the NXP dongle. I should have fixed all places where the library was waiting for a synchronous response over the asynchronous one but, obviously, I could have missed someone.
+To complain with the ZStack, the library contains a function called waitAndLock3WayConversation, where 3Way means the request, the synchronous response and the callback. That function uses a map to avoid that more request of the same type are sent so that the system doesn't know which request the response is for. Actually the function never checks that the conversation is performed that way, so it could be used also for the message exchange as it is done through the NXP dongle. I should have fixed all places where the library was waiting for a synchronous response over the asynchronous one but, obviously, I could have missed someone.  
+
+Some incoming packets (Asynchronous responses) from ZStack reports the source address in their contents where the equivalent packet from BeeStack does not. Maybe there are still some methods that expect to found this field. They should be modified to avoid run-time exceptions.