I have been trying to send more than 19 bytes of application data from the AP to the EZ430 Chronos for days without sucess (even 20 bytes fails)
For example, for just 1 more byte (i.e. 20 instread of 19), I modified -DMAX_APP_PAYLOAD to 20 (was 19) in smpl_nwk_config.dat, SIMPLICITI_MAX_PAYLOAD_LENGTH to 33 (was 32) and BM_SYNC_DATA_LENGTH to 20 (was 19) in simpliciti.h for packet handling in both the AP and Chronos code, recompiled, flashed and confirmed sucesfully to both devices.
As before the Chonos is able to Join and Link to the AP, but when I send a 20 byte packet, it is never received by the Chronos. Remember, the exact same code with a 19 byte payload works fine - and the theoretical limit for the EZ430/CC1111 radsios should only be around 50bytes.
With our packet sniffer we can confirm that the 20 byte playloads being transmitted in well fomed SimpliciTI packets as they should.
So why isnt the Chronos recieving the packets? Is there some radio specified size limit I'm not aware of, or some un-matched check on packet sizes I cant find in the code? It looks like the radio VECTOR into the radio_ISR(void) function works fine for the JoinAck and LinkAck messages, and TX works fine, but 20 byte incomming packets are simply lost somewhere along the line.
Has anyone been able to send application payloads larger than 19 bytes using the EZ430 Chronos and its CC1111 AP? If so, please let me know how, and if its not possible, please let me know why :-) Many thanks :-)
From MRFI_RADIO_MAX_PKTLEN in mrfi_radio.c we can see that the maximum packet size for this radio is 61 bytes.
Given that the currently specified maximum Simpliciti packet is just 31 bytes (confirmed with sniffer using 19 byte app payload - made up of 1(length)+8(2*address)+19(App Payload)+3(Non secure Network header), there are still 30 bytes free?
I tested the end to end communication (AP and Chronos) with the Maximum Application Payload set to 18 bytes rather than 19 bytes and it worked fine... so there must be some unseen limit at 19 bytes??? Any input welcome :-)
I suspect the problem lies with the EZ430 Chronos SimpliciTI radio receiving stack as I am able to send packets much larger than 19 bytes (40 went fine at the last test) without any problems from the AP. Does anyone have any feedback as to why SimpliciTI seems to restrict receiving packets app payload to 19 bytes?
I never tried Simpliciti since I rolled my own but did you check the packet length settings of both sides? The packet length modes are in the PKTCTRL0 register, bit 1:0. If it's fixed (00), then the PKTLEN register contains the actual packet length. If the packet length is set to variable (01) then the first byte of the payload sets the packet length. Just an idea...
SimpliciTI should allow you up to 50 bytes of application payload data on the CC430 device. Have you re-compiled the SimpliciTI library code included in the Chronos project? Note that the SimpliciTI stack is pre-compiled into a library and then included into the Chronos project. If this library was compiled with a limit of 19 bytes then the dynamic check of your packet being smaller than the size of the output buffer will fail and you will not be allowed to send the packet.
If this post has answered your question, even if not the way you wanted, please indicate so by clicking the Verify Answer button on this post.Please start a new thread if your question is not closely aligned with the original post in this thread as it makes searches more effective.If responding to a post please click the Reply button on the post you are responding to rather than merely defaulting to the bottom post.
Many thanks for the feedback Greg and Jim
Greg, unfortunately I don't think St. Feuillien is in luck as PKTCTRL0, bit 1:0 is set to (01) in all configurations, i.e. variable packet length... hmmm.
Jim, I am sucesfully building the "Unrestricted IAR Workbench" versions of the AP and Chronos projects which, as I understand it, do re-compile the SimpliciTI stack along with ones own code (unlike the "Limited IAR Kickstart" versions).
But, perhaps this assuption was wrong. If so, how does one go about recompiling the SimpliciTI project? There are no other workspace files in the Chronos release so I presume Id have to download some other full version and integrate it... but how?
Thanks again, have a great day, Mike
Nope, Ive double checked that in the "Unrestricted IAR Workbench" project versions, the SimpliciTI code is definately completely rebuilt (I even removed the origional CC430_End_Device_868MHz.r43 library just to be sure). Likewise, other changes Ive made to the SImpliciTI stack (independantly tested) ARE being included and are modifying behaviour correctly.
Interestingly, I am able to transmit greater than 19 byte app payloads from the AP, confirmed with the sniffer (which must ALSO be reading the greater than 19 bytes to display them!) they just arent being recieved by the EZ430 Chronos stack.
Perhaps someone could try simply modifying -DMAX_APP_PAYLOAD=19 to -DMAX_APP_PAYLOAD=20 on their AP and Chronos to see if you encounter the same bahaviour..
Correct, in the unrestricted form, SimpliciTI is completely rebuilt each time you compile. Note that if you make changes to the .dat files, i.e. change the MAX_APP_PAYLOAD macro, you need to do a rebuild all as the .dat files do not alway properly trigger the correct dependencies in the project build operation.
In the chronos implementation there are two additional macros to manage.
BM_SYNC_DATA_LENGTH which is set to 19 bytes. This value is used during the sync process and is sent at regular intervals until a link is established.
SIMPLICITI_MAX_PAYLOAD_LENGTH which is set to 32 bytes. This value is only used when declaring the data buffer array.
There are only three places in the chronos code where calls to SMPL_SendOpt are made,
If you by chance copied the line from the code using the BM_SYNC_DATA_LENGTH macro for the amount of information to send, then you will always be sending 19 bytes of information.
Your calls to SMPL_Send(Opt) should include the size of your particular message either by using a dynamic variable or the sizeof operator.
I can confirm that I do clean and rebuild the whole project each time I make a change to the configuration files. - just to be on the safe side.
Likewise, I have already increased these two defines to correspond with the increase in payload... i.e when I tested by increasing the application payload by 5 bytes I made -DMAX_APP_PAYLOAD=24, BM_SYNC_DATA_LENGTH=24 and SIMPLICITI_MAX_PAYLOAD_LENGTH=37. (I also experimented with the MRFI __mrfi_MAX_PAYLOAD_SIZE__ defines but its clear that these are not used when -DMAX_APP_PAYLOAD is specified.
Interestingly, I have just tested that I am able to SEND packets with an App Payload of 24 bytes (i.e. 5 more than 19 default) from the Chronos to the AP where they ARE received and processed correctly.
It is only when I send 24 byte app payload packets from the AP (to which I have made identical stack changes) to the Chronos that they are NOT received... hmm.
TX of well formatted 24 byte app payload packets in both directions has been verified with the sniffer.
I think it may be something in the Radio drivers as I suspect that the incoming packets might not vector correctly into MRFI_RadioIsr().. and hence dont appear in the INQ (queue) and ultimately to the application layer. Any thoughts welcome?
In the access point project, in the simpliciti_main function in the Main_AP_BM.c file, the received packet lengths are explicitly tested against 2, 4, and 19 bytes of length. Any packets not of these lengths are discarded. Note that these values are magic numbers and not tied to any macro definitions.
Also, the access point will automatically overwrite the current Link ID if another link is attempted by toggling power on the watch, restarting the watch when attached to the debugging dongle, or if another SimpliciTI node attempts to link with the same Link Token. The code will handle this quite fine until the number of ports available for a given address runs out which will be somewhere around 30 links from the same address even though there are an additional 220+ Link ID's left to allocate. Make sure you reset the access point every time you reset the watch to keep your debugging consistent.
Finally, the watch tends to turn off the SimpliciTI stack after many operations and if the ISR sees the stack is shut down, it will not vector to the SimpliciTI stack any packets received. Search for SIMPLICITI_OFF to find the places where this occurs.
Thanks Jon - you are 100% on the ball but alas, none of these excellent thoughts point to the solution... yet... we just need to keep narrowing it down.
1) My mods to the AP firmware already include the addition of my own incoming packet size magic number (i.e. 24 for now) and this is working fine.
2) I do reset the AP regularly, but as I only see this behaviour with >19 byte packets, I suspect the LinkID list is not key here,
3) I have confimed that the code around the SIMPLICITI_OFF checks is definately not being called inadvertently and as above, because the failure behaviour is only for >19 bytes packets - its unlikely to be the cause.
To summarise the behaviour, following the above detailed changes to the packet size defines, with some standard test Application Layer software and the necessary magic number changes:
<=19 byte packets are being TXd and RXd by both the AP and Chronos without any problems :-)
>19 byte packets are being successfully TXd by both the AP and Chronos, and are being RXd and processed in the AP, but NOT in the Chronos :-(
So, during operation, from observing the Packet Sniffer, in both conditions the bidirectional Join and Link negotiations work fine, then the Chronos starts sending short R2R packets every 2 seconds - no problem. The AP recognises these and transmits a response BUT >19 byte packets are never vectored into the SimpliciTI stack from the radio, whereas <=19 byte packets are correctly received and the application runs fine!
Furthermore, my Chronos Applciation code times out after 30 seconds if no messages are received from the AP, causing the stack to reset and restart. This works fine for both <=19 and >19 byte packets and both the bidirectional reJoin and reLink stages work perfectly, time and time again.... but this gets us back to the condition where the if the AP sends <=19 byte packets there is no problem, but >19 bye packets simply dont appear in the Chronos SimpliciTI stack...and it restarts after 30s again.
As such, I suspect there is SOMETHING in the Radio code causing the mischief, but I cant find it. So... umm.. if you are extremely bored and sufficiently inquisitive, please could you, or someone else, try simply increasing the packet size in the Chronos & AP code to see if you get the same behaviour :-) Best wishes :-)
Have you commented out the calls to the BlueRobin code in the ISR? You should change this code to simply call the MRFI_RadioIsr function to verify wheter or not the packet is received as expected.
Do you need to keep the BlueRobbin stack in the code? Are you still trying to keep the GUI operational? If your final application is ONLY SimpliciTI based, you should download the normal SimpliciTI stack and work from there. That way you will eliminate all the extraneous stuff not needed. You can always pull in the driver code for the peripherals and such.
I am actually working on the same functionality!
I can help you to debug the code, do you have it on a github repository so I can test it?
I have the IAR workbench 8.11 with CCDEbugger and can flash and debug the CC1111EMK as well as the CC1111 Chronos dongle.
Fee free to get in contact with me.
All content and materials on this site are provided "as is". TI and its respective suppliers and providers of content make no representations about the suitability of these materials for any purpose and disclaim all warranties and conditions with regard to these materials, including but not limited to all implied warranties and conditions of merchantability, fitness for a particular purpose, title and non-infringement of any third party intellectual property right. TI and its respective suppliers and providers of content make no representations about the suitability of these materials for any purpose and disclaim all warranties and conditions with respect to these materials. No license, either express or implied, by estoppel or otherwise, is granted by TI. Use of the information on this site may require a license from a third party, or a license from TI.
TI is a global semiconductor design and manufacturing company. Innovate with 100,000+ analog ICs andembedded processors, along with software, tools and the industry’s largest sales/support staff.