I’ve coded up a driver to build API packets using a PIC microntroller. Everything seems to be working fine, except trying to set the network key (KY). I’ve been able to set just about every value I need by building AT command frames and listening for the response frame. When I build up an AT command frame to issue a KY command along with my 128bit key, I get no response frame and the command isn’t applied.
I’ve done a memory dump from the MCU to verify that I have built the frame correctly. Is there a barrier to issuing KY commands in API mode that I have missed?
An additional interesting thing I noticed. Doing a restore on an xBee-24-ZB module doesn’t erase the security key. If I restore, and turn on encryption mode (EE=1) I find that the radio has retained the shared key.
It’s not a huge deal, and in fact helps slightly in my MCU firmware by removing the absolute need to keep the shared key on an EEPROM in order to do a full local reconfigure.
Anyway, if anyone has any ideas about a KY frame not sticking or getting a response packet . . . .
I did another validation of the frame I am building and it all seems right to me. Length, type, checksum, data . . everything appears to be a perfectly valid AT Command frame for API mode. Still, the unit doesn’t send a response frame of any kind and the command doesn’t take effect.
X-CTU can set a KY value in API mode, so it is obviously possible. I’ve been back through the docs a couple times now and can’t find anything that should be getting in the way.
I tweaked something minor last night on the output stream of the MCU. Didn’t get a chance to try it out until just now but it seems to have done the trick. Stupid mistake on my part. Thanks to everyone who chimed in.
It sounds like its getting set, there’s just no way to read/verify that because KY is write-only.
Understood. But I should at least get an AT Command Response packet back with an OK indicator, shouldn’t I?
I’m not getting a response packet at all from the KY command.
What does your API ‘AT command’ frame look like?
In the ‘AT command’ frame there is a byte that when set to 0x00 means do not respond. Could this be the issue?
Thanks for the response.
You’re referring to the Frame ID byte. I’m using a value of 0x05 in that field to ensure I always get a response frame. The frame I am building looks like this:
0x7e start delimiter
0x00 length MSB
0x15 length LSB 21-dec
0x08 frame type AT command
0x05 frame ID
0x4B First character of AT command “K”
0x59 Second character of AT command “Y”
0x34 16 bytes of the security key
0xD6 Calculated Checksum
I’ve obscured my actual security code here, and done the checksum by hand. Rest assured, I’ve gone through my checksum calculation a dozen times to make sure I am getting it right in the real frame I am sending out.
I ship this frame out to the xBee and all I get is crickets. Nothing. No response of any kind. Every other AT command I send gets a response frame, even if it is an error frame. Same on my TX-request frames. I’m certain there is something on my end causing this, but I can’t think what it might be. It looks like a valid AT command frame to me.
Just had to ask in case you missed something but since the frame ID != 0 then a response should be forthcoming according to the document (doc #90000976_C, pages 87,88).
Pages 58-61 talk about setting up security registers but fails to be explicit as to the exact exchange.
My guess is what Admin is not saying:
Since the register is write only and can not be read (even within a nodes own code) there is no way for a node to verify if the correct value was written to its own register. Therefore no response is send back to the coordinator. This is not what is described in the document.
It would be nice to have a response so that at least the coordinator knows that the destination node did receive the command correctly, even if it can’t verify the correct value was written. That is what I read in the documents as to the type 0x88 response frame Command Status.
This looks to be a huge oversight in the design and documentation if this is really how it works. I guess one must just blindly set 128-bit encryption keys and hope nothing was corrupted along the way.
Unless there is another page in the document I didn’t find.
In replicating this on my end I do get the proper response. I am sending:
7E 00 14 08 01 4B 59 12 34 56 78 90 12 34 56 78 90 12 34 56 78 90 AB BB
The response frame that I get is:
7E 00 05 88 01 4B 59 00 D2
I suspect something else is wrong.
What version of firmware are you using? I am using 2x64. Are you enabling encryption at any point (EE)? I don’t think that it should effect it but maybe it could help in attempting to recreate.
I’m on the latest firmware version for xB24-ZB End Device API. Sorry I don’t have the rev number in front of me, but it only downloaded that rev in X-CTU this week. It’s definitely the latest rev.
EE is enabled on the unit as well as the coordinator.
I’m going back through all my driver code right now. I somehow suspect I’m dropping something from my frame string before sending it, resulting in an invalid frame.
Thanks for verifying that a response does in fact happen on that command.