I have just downloaded SimpliciTI v1.2.0 and tried to run the Simple Peer-to-Peer example code on the CC2510 SoC. The compiler that I am using is the IAR EW8051 v8.11. I can run successfully the LinkTo and LinkListen applications up to step 4 (see page 27 of swra243). However, when I push a button on the talker (LinkTo), the link can not be established. Both LEDs on the Talker are blinking (linking failed). And LED2 on the Listener is always ON (LED1 is always OFF.) as if the Listener never hears the Link Frame from the Talker.
I used the spectrum analyzer to check the behavior of the Talker and found that the Talker is sending frames on Channel 3 (2425.7 MHz).
Then, I tried the example code on both the CC2510-CC2511DK platform (with SmartRF04EB) and the CC2510 Mini DK (with the code porting described in DN118 document). Both of them have the same performance. Please note that I tried the example code on two CC2510 DK boards (with SmartRF04EB) and then tried the example code on two CC2510 Mini DK boards. None of them works.
I then tried SimpliciTI v1.1.1 on these platforms (by using the same IAR EW8051 v8.11 compiler). The problem remains the same.
I then tried the Access Point as Data Hub example code on these platforms by using the IAR EW8051 v8.11 compiler. There is no problem with this example at all (for both SimpliciTI v1.2.0 and v1.1.1 on both of the platforms).
It seems that the problem happens in the following pair of APIs for the peer links.
* smplStatus_t SMPL_LinkListen(linkID_t *linkID)
* smplStatus_t SMPL_Link(linkID_t *lid)
I wonder if it is caused by the new version (IAR EW8051 v8.11) of the compiler or something else?
How should I debug this problem?
have you tried to see whether the nodes send the correct packets using the SmartRF Packet Sniffer (http://www.ti.com/tool/packet-sniffer)?
Have you also made sure that both applications use the same radio settings (basically the same smartrf_CC2510.h in this case).
Another thing is that i have two versions of IAR 8051 compilers on my computer: 8.10 and 7.60. Somehow i can only compiler the codes using the 7.60.
Hope this helps.
In reply to Leo Hendrawan:
Thanks for the response :-)
I haven't tried to decode the packets because I am pretty new to the SimpliciTI stack (still in the process of learning the details of it). I will try to do this though and report the results back to you.
The radio settings are the same (using the same smartrf_CC2510.h). I just compiled the Talker and Listener right out of the box (I didn't change anything in the example code).
About your compiler issue. If you have problem with the "$TOOLKIT_DIR$\config\lnk51ew_cc2510.xcl" linker file in IAR EW8051 v8.10, you probably need to change this to "$TOOLKIT_DIR$\config\devices\Texas Instruments\lnk51ew_cc2510F32.xcl". The IAR compiler has changed the name and location of the linker file in the new versions.
Please try to see if this solves your compiler problem. If so, could you please try the IAR EW8051 v8.11 to see if you can get the same issue that I am having now? Also, can you get SimpliciTI v1.2.0 (Simple Peer-to-Peer) working properly using IAR EW8051 v7.60? Based on the SimpliciTI document, SimpliciTI v1.2.0 is developed on IAR EW8051 v7.60. So, I assume that should work. Please let me know what you find.
Please also try the packet sniffer on your side and let me know the results if you get the same issue as mine.
SimpliciTI was developed and tested using IAR IDE 8051 v7.51. I know that version 8.x became available in late stages of final test of SimpliciTI release 1.2. We initially tested it, but found more issues than we could handle within the timeframe allocated. So, it was decided to stick with version 7.51. Please download and install the exact same version of IAR as recommneded in the users guide.
In reply to TA12012:
I dowloaded both IAR EW8051 v7.51A and v7.60. Here is a list of things that I have tried.
* Compile Simple Peer-to-Peer SimpliciTI v1.1.1 using IAR EW8051 v7.51A and run it on CC2510DK. Result: Same problem remains (Please see the initial post for details of the problem.).
* Compile Simple Peer-to-Peer SimpliciTI v1.1.1 using IAR EW8051 v7.51A and run it on CC2510 Mini DK. Result: Same problem remains.
* Compile Simple Peer-to-Peer SimpliciTI v1.2.0 using IAR EW8051 v7.60 and run it on CC2510 DK. Result: Same problem remains.
* Compile Simple Peer-to-Peer SimpliciTI v1.2.0 using IAR EW8051 v7.60 and run it on CC2510 Mini DK. Result: Same problem remains.
Now, I am confused somehow. These are the IAR versions that the author(s) of the SimpliciTI used to develop the SimpliciTI. How can this happen?
I also used a packet sniffer to capture the packets on the LinkTo node (Talker). Please see attached 7356.SimpliciTI-IAR-1.2.0_on_CC2510DK.psdSimpliciTI-IAR-1.2.0_on_CC2510DK.psd file for detailed information. It looks to me that the Talker (which is a client) sends out a Join Request packet at the start and end of the operation (power on and power down). It also sends out Link Request frames periodically after a button has been pushed. The packet structure looks good to me. Can you please help me to check if there is anything wrong with these packets?
If the packets are correct, shall I assume that the problem is at the receiver side (the Listener which is a master)? If so, how should I debug this problem?
In reply to SkyBlue:
I just found out from the packet structure that I am using the default device address for both the Talker and the Listener (0x 79 56 34 12). After I changed them to different values for the Talker and the Listener, the Simple Peer-to-Peer example works well now.
The packet sniffer really helps!!!
Thank you both very much for your help :-)
glad to hear that you made it. Sorry, I forgot to mention this also, altough i also had the same problem when i started with the Simple-Peer-To-Peer application. So i added this to the top of the SimpliciTI FAQ list. Good luck then playing further with SimpliciTI.
Thanks for directing me to the SimpliciTI FAQ page. Now I have another question and I hope either you or TA can shed some lights on this issue.
In the Simple Peer-to-Peer example, there is a function which can generate a random address for the device.
This function is called before the initialization of the SimpliciTI stack (SMPL_Init(sRxCallback)) when the I_WANT_TO_CHANGE_DEFAULT_ROM_DEVICE_ADDRESS_PSEUDO_CODE macro is defined. However, this function is neither defined nor declared in the Simple Peer-to-Peer example. So I used the MRFI_RandomByte( ) function to replace this function as shown below.
// === Start of Code Segment ===
/* replace the createRandomAddress function with the RandomByte() function */
lAddr.addr = MRFI_RandomByte( );
lAddr.addr = MRFI_RandomByte( );
lAddr.addr = MRFI_RandomByte( );
lAddr.addr = MRFI_RandomByte( );
SMPL_Ioctl(IOCTL_OBJ_ADDR, IOCTL_ACT_SET, &lAddr);
#endif /* I_WANT_TO_CHANGE_DEFAULT_ROM_DEVICE_ADDRESS_PSEUDO_CODE */
// === End of Code Segment ===
I hoped that this could give me different device addresses between the two nodes without me having to manually change the device address in the macro. Unfortunately, it turns out that the RandomByte() does generate four PN bytes (0x 01 03 00 80 in this case) but both of the two nodes have the same PN bytes! I think I can change the LFSR seed of the Random Number Generator but this goes back to the point that I have to manually change something before compilation. Is there any way to solve this issue?
Unfortunately its pretty dificult to make a truely random number of a small MCU. I was pointing towards this applications note on one way to get a random number.
I hope it helps,/TA
do you really need to generate random numbers? I used the code for connecting a "remote" device with a "driver" device some days ago, and what i did is that i hardcoded the address in the code like this:
addr_t lAddr; lAddr.addr = 'D'; lAddr.addr = 'R'; lAddr.addr = 'V'; lAddr.addr = 'R'; SMPL_Ioctl(IOCTL_OBJ_ADDR, IOCTL_ACT_SET, &lAddr);
addr_t lAddr; lAddr.addr = 'R'; lAddr.addr = 'E'; lAddr.addr = 'M'; lAddr.addr = 'T'; SMPL_Ioctl(IOCTL_OBJ_ADDR, IOCTL_ACT_SET, &lAddr);This will make sure that the THIS_DEVICE_ADDRESS definition in the configuration file is ignored and the stack will use the addresses above instead.
Oh yes, i forgot to comment something. I do not really understand how the random generator works for the CC2510, but i think as a general idea it is not really easy to generate random numbers on identical devices. I had even experience before, that using the rand() function (http://pubs.opengroup.org/onlinepubs/009695399/functions/rand.html) on identical devices, will most probably generate the same number.
I think the SLAA338 above is possible in this case, because the deviation of the VLO clock used. The VLO clock is a very low power clock source on MSP430 devices, but as an trade off it has a really poor accuracy. For example on a the MSP430F5438A datasheet, it is stated the VLO to have the following values:
- Min : 6 kHz
- Typ: 9.4 kHz
- Max: 14 kHz.
Therefore the probability that identical deviced have the same VLO frequency is pretty low.
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.