Need a simple example on how to configure CC2510/CC2511 for RF Communication.

Hi Guillermo,

I would start by verifying that your hardware is ok. The easiest way to do this is to let SmartRF Studio control both sides of your link and try to send packets from one board to another. If this works ok, you can continue with your own SW development. If not you must start do debug your boards with a spectrum analyzer (is frequency correct, does the spectrum look ok, etc.).

I am not a SW guy myself, but I guess the example found here should be a good starting point.

Cheers,

Fredrik

I would highly recommend that you get one of the kits to have a known good reference system that you can use to test against your own hardware.

The CC2510DK-MINI kit is a nice entry level kit for the CC2510, and it is not very expensive.

You can also take a look at the software examples for both the full DK (CC2510-CC2511DK) and the mini kit to get some ideas about how to control the radios on these MCUs.

CC1110 and CC2510 Mini DK Software Example (www.ti.com/lit/zip/swrc133)
CC1110 and CC2510 PER Test (www.ti.com/lit/zip/swrc085)

You can also use SmartRF Studio to test your own hardware.

Fredrik, Thank you for your answer.
I tried SmartRF Studio with my hardware, SmartRF Studio had no trouble recognizing the microprocessor, but when I try to either send or receive packets it comes back with an error:

Communication Error!.
Not able to read from Device.
Check USB Connection.

Do I need to download any special software on the Micro prior to using SmartRF?

Any idea?

Thank you for your help. 

Mr. M,

Thank you for your letter and suggestions. 

The CC2510DK-MINI as a reference is a great idea, but TI Store is out of stock, Arrow is out of stock, Thankfully Mouser had it in stock so I just purchase one.

Once I receive it I'll give it a try.

Thank you.

Guillermo,

The error you get from SmartRF Studio indicates that the connection between the CC-Debugger and your device is not very stable. Please verify that all the signals are properly connected, including ground and the target voltage sense signal, and that you're not using very long cables between the device and debugger.

Does other things in Studio work, like continuous RX?

Mr. M:

Receiving packets also report the same problem.

I have no issues flashing software on my boards using the standard dongle,

Is the RFstudio somewhat more delicate than the flashing software?

What do you mean by "flashing software on my boards using the standard dongle"? What standard dongle? 

For the CC2510, SmartRF Studio uses exactly the same interface to control the chip as we do with SmartRF Flash Programmer. If the latter works, the former should also work. One difference is that you can change the interface speed in the flash programmer (slow or fast). Have you set it to slow?

Would you mind sharing parts of your schematics showing how you connect the debugger to the chip?

I use the TI CC Debugger and TI SmartFlash software to program all my boards, without any issue thus far.

I was not aware of any speed setting. The CC Debugger only has the Reset Button and the Red/Green LED.

Attached please find schematic of the test board, I simplified to just have a LED and RS232 port for feedback. I build two of them one to send packets and another to receive them. The antenna is a Dipole based on the specifications from SWRA118.pdf

1537.BTM-switch-for feedback.pdf

This board uses an RJ45 conector for programing, the RJ45 to the Debugger uses the following circuit to map the pins.

0284.TI programing interface.pdf

The RJ45 cable that I'm using is only 4 inches long.

I want to believe that when using the RFStudio, the software in my board does not matter, right? I mean I hope that RFStudio takes over the Micro, right?

Thank  you for your help.

The speed setting I was talking about is a setting in the Flash Programmer GUI. However, if you haven't touched this setting so far and flash programming works, then the interface speed is not what's causing the problem.

When SmartRF Studio runs, it takes over the control of the chip. Software already programmed on the chip will not be running.

As indicated by the schematics, I assume you're powering your boards from the USB connector, right? You do power the board separately when it is connected to the debugger?

If I understand correctly, you only get this communication error when you try to send and receive packets. But you can open the device control panel without any problems and read current register values?

Did you try the Continuous RX (not packet RX) feature in Studio? Still the same error? 

Today I received and tested the CC2510DK-MINI kit, I tested to get a feel of how things should work.

The Kit Boards worked perfectly OK, as expected.

As for my boards:

1. RFStudio detects the device.
2. When Selecting "Show Connected Devices" and Opening the Device Control Panel, a screen with status appears, it goes very quicly but it looks that is doing the same initialization as with the Kit Boards (Identify device, Configure  Device, Setup something, Initialize RF Device, etc)

When the Parameter screen appears I can see some differences:

1. The Base frequency appears on zeros, the Kit boards start with a default value 
2. On The Register View screen I can see several registers in Red all with 0 values. On the Kit board I saw all in Green

When changing the frequency, the values become green on the Register view screen.

If I try the Refresh button the Base frequency goes back to Zero.

So while the Flash Programmer has no problem, and the RFStudio can detect the device, there is an issue of actually writing and reading to the RF registers.

Do you have any idea of how I should proceed next?

Thank you for your help

The only way I can explain this is that there is something wrong with your hardware. Recheck the connection between the debugger and the chip, and make sure you have a stable power supply which is properly decoupled and that the ground connections, including grounding of the pad under the chip, is done according to our recommendations.

I took a new look at the schematics you provided. You can try to remove the pull-up on DC (it is not required). Recheck decoupling of DVDD and AVDD. Do you follow our reference design? You should also consider adding a small RC filter on the reset line.

Mr. M,

I found the reason I was having problems with the RFStudio. It turns out that as I was powering my board with its own power supply the board could not be properly controlled by the RFSTUDIO, as Soon as I removed my power and supported the board only trough the power provided by the CC Debugger, all became operational.

Now I can get to the registers and see the activity.

This could probably help someone else that encounters the same issue.

Thank you for your support.

Mr. M.

Just when I thought, that I had it made.... I'm still having some issues.

My testing setup:

I have two computers, each with its own CC Debugger.
One of the CC Debugger is connected to a CC2510DK-mini as reference.
The other I use to connect to my own boards. 

I'm able to use the RFStudio and confirm transmission and reception using the "Continuous TX" and the  "Continuous RX" options

But when I try to use the "Packet RX" or "Packet TX" can seem to be able to make it work. 
Actually I did saw it work once but then when I tried to duplicate the process, could not make it work again.

Same thing with the "Easy Mode" I saw it working one time and then could not duplicate it again.

Note: Using Two of the CC2510DK-mini work perfectly, so the issue is definitely still with my boards, But I have not been able to find the cause.

Any suggestions would be great.

Guillermo,

Do you have access to a spectum analyzer to check the RF output of your boards?

/Fredrik

Frederik,

I do not have a Spectrum analyzer, but I was thinking of buying the following:

http://www.metageek.net/products/wi-spy/

do you think that would help?

What would you like me to measure?

Frederik,

One more question/doubt, I wonder if this has something to do with my issues with setting the Radio:

Should I use "XDATA Stack reentrant" or "PDATA Stack Reentrant"? 

On my project I'm currently setting the Calling convention on General Options/Target of the IAR workbench as "PDATA Stack reentrant" and the compile is succesful.
If I try to set the calling convention as "XDATA Stack reentrant" then the Linker reports several errors:

Error[e16]: Segment XSTACK (size: 0xeff align: 0) is too long for segment definition. At least 0x15d more bytes needed. The problem occurred while processing the segment
placement command "-Z(XDATA)XSTACK+_XDATA_STACK_SIZE=_XDATA0_START-_XDATA0_END", where at the moment of placement the available memory ranges were
"XDATA:f000-fda1"
Reserved ranges relevant to this placement:
XDATA:f000-fda1 XSTACK
BIT:0-7 BREG
BIT:80-87 SFR_AN
BIT:a8-af SFR_AN
BIT:b8-c7 SFR_AN
BIT:e8-ef SFR_AN
BIT:f8-ff SFR_AN
Error[e16]: Segment XDATA_Z (size: 0x54 align: 0) is too long for segment definition. At least 0x54 more bytes needed. The problem occurred while processing the segment
placement command "-Z(XDATA)XDATA_Z,XDATA_I=_XDATA0_START-_XDATA0_END", where at the moment of placement the available memory ranges were "-none-"
Reserved ranges relevant to this placement:
XDATA:f000-fda1 XSTACK
BIT:0-7 BREG
BIT:80-87 SFR_AN
BIT:a8-af SFR_AN
BIT:b8-c7 SFR_AN
BIT:e8-ef SFR_AN
BIT:f8-ff SFR_AN
Error[e16]: Segment XDATA_I (size: 0x8 align: 0) is too long for segment definition. At least 0x8 more bytes needed. The problem occurred while processing the segment
placement command "-Z(XDATA)XDATA_Z,XDATA_I=_XDATA0_START-_XDATA0_END", where at the moment of placement the available memory ranges were "-none-"
Reserved ranges relevant to this placement:
XDATA:f000-fda1 XSTACK
BIT:0-7 BREG
BIT:80-87 SFR_AN
BIT:a8-af SFR_AN
BIT:b8-c7 SFR_AN
BIT:e8-ef SFR_AN
BIT:f8-ff SFR_AN
Error[e24]: Segment INTVEC (seg part no 18, symbol "p0_ISR::??INTVEC 107" in module "IO port setting", address [0-85]) overlaps segment XDATA_Z (seg part no 20, symbol
"pktSentFlag" in module "RFCONFIG", address [0-53])
Error[e24]: Segment INTVEC (seg part no 18, symbol "p0_ISR::??INTVEC 107" in module "IO port setting", address [0-85]) overlaps segment XDATA_I (seg part no 16, symbol
"__Constant_24ed20" in module "main", address [0-7])
Error[e24]: Segment XDATA_Z (seg part no 20, symbol "pktSentFlag" in module "RFCONFIG", address [0-53]) overlaps segment XDATA_I (seg part no 16, symbol
"__Constant_24ed20" in module "main", address [0-7])
Error while running Linker

Total number of errors: 6

Hi guillermo,

There's no easy answer to your question whether to use PDATA or XDATA stack. PDATA access is slightly quicker than XDATA, but it is limited in size. I recommend that you read about PDATA and XDATA in IAR's help documentation to learn more about the two.

The problem you see with the linker is that you have set aside 0xEFF (3839) bytes for the stack. That's normally way too much. You couls reduce it to e.g. 0xFF (in the project options, General Options, in the Stack/Heap tab).

As for a spectrum analyzer, the one you refer to could work. We also have a "poor man's" analyzer solution with the CC2511 USB dongle and this software: http://e2e.ti.com/support/low_power_rf/f/155/t/17252.aspx (Spectrum Indicator).

Hi Guillermo,

Good to hear that you solved your problem. Have a look at this app note for details on how the crystal oscillator works: http://www.ti.com/litv/pdf/swra372a

Cheers,

Fredrik

Hi 

I wonder if you have any simple code examples for the cc2510 mini development kit.

I just need a simple TX RX code in order to get started.

swrc085b is to much for simple code snippet, same for swrc117. 

Thanks for your help

The PER test in the CC2510 software package www.ti.com/lit/zip/swrc085 should be easy to use for setting up the radio to receive and transmit packages.

Alternatively, you can take a look at the the SimpliciTI based code example for the CC2510 mini kit. You'll find the code here www.ti,com/lit/zip/swrc133.