CC1310: RF_runCmd hangs in EasyLink_init() - Probably a crystal issue..?

Craig Easdale

Part Number: CC1310

I am trying to port an example to custom hardware, but I've noticed that when I do this I get a problem that effectively halts the whole application.

When EasyLink_init() is first called, the function will get all the way to here:

    //Set the frequency
    RF_runCmd(rfHandle, (RF_Op*)&EasyLink_cmdFs, RF_PriorityNormal, 0, //asyncCmdCallback,
            EASYLINK_RF_EVENT_MASK);

where it then hangs. I can't see what's happening inside that function since it seems to be extern'd to somewhere else.

What's strange is this does not happen on the CC1310 LaunchPad. The only changes I have made are to the pin configuration, so I have no idea what might be causing this. Any suggestions?

over 7 years ago

0 TA12012 over 7 years ago

TI__Mastermind 36375 points

Craig,

To me it sounds like the clocks on your custom board are not starting up when needed. The likely clock is the 24MHz XTAL, it is only started just before the RF is engaged.

I would recommend using a high impedance probe to see how the 24MHz starts and stops on a LaunchPAD and compare it to your custom board.

Regards,
/TA

0 Craig Easdale over 7 years ago in reply to TA12012

Expert 2160 points

Thanks, I'll have a look into that and report back.

If the clock isn't starting, why might that be? wrong clock or capacitor values?

0 SVS over 7 years ago in reply to Craig Easdale

TI__Genius 9705 points

Hi,

Clock related issues are typically caused by crystals that do not meet the spec provided in CC1310 datasheet. Also, on CC1310, 24MHz crystal does not need external load capacitors by default . Please refer to the following wiki if you need to change the internal load capacitor for the crystal on your board.

processors.wiki.ti.com/.../CC26xx_Tips_and_Tricks

Regards,

0 Craig Easdale over 7 years ago in reply to SVS

Expert 2160 points

Hello again, finally managed to do some debugging of the issue.

I noticed a big difference in comparison between the LaunchPad and my own hardware. I don't know exactly why this difference exists, but I hoped someone might be able to take a look at the scope trace and provide some insight. The bottom trace in grey is from the launchpad, the top in yellow is from the custom hardware. Both are on the same voltage and time scales.

Any thoughts?

0 Craig Easdale over 7 years ago in reply to Craig Easdale

Expert 2160 points

I should add, I removed the external load capacitors on the crystal to take these measurements.

Does this look like a load capacitance issue? If so, what can I do to resolve it?

0 Craig Easdale over 7 years ago in reply to Craig Easdale

Expert 2160 points

Hi, Could someone please respond to this?

It was a fairly disruptive and urgent problem when I first posted 10 days ago and is still unresolved! Thanks.

0 SVS over 7 years ago in reply to Craig Easdale

TI__Genius 9705 points

Can you please share your board schematic and layout.

Also where on the board and how are you observing these signals? What crystal are you using and what is the load needed as per crystal spec?

0 Craig Easdale over 7 years ago in reply to SVS

Expert 2160 points

Here is the schematic... I have removed the two capacitors (C13 + C20) on X1 since being notified they were not needed.

I have soldered small wires to the pads where the capacitors used to be connected, right next to the crystal.

Additionally, the Crystal being tested on the hardware is the X1E000351001512 (Datasheet)., The one in the schematic was unavailable but it on backorder. The X1E000351001512 is near identical apart from the slightly higher load capacitance (10pF)

0 Craig Easdale over 6 years ago in reply to Craig Easdale

Expert 2160 points

I forgot to mention, the system is being powered from the XDS debugger of the launchpad when I have observed the problem. I have not tried an alternative power source.

0 Craig Easdale over 6 years ago in reply to Craig Easdale

Expert 2160 points

This issue is still unresolved and still urgent, I'd really appreciate if someone would follow up with this ASAP.

0 stomp over 6 years ago in reply to Craig Easdale

Genius 4615 points

I'm sitting here at my desk at 9:15pm debugging a similar issue to yours.

We had external caps on our crystal, which were causing issues for the radio, after these were removed we had good success.

During testing today we were finding the CMD_Fs was failing randomly, error code 0x86. We believe this is related to our crystal too. Could be the same issue as you are having (i.e. a failure of the Fs command would prevent your radio from working).

Here is a link that is worth a read: www.ti.com/.../swra495e.pdf

Cheers.

0 Siri over 6 years ago in reply to stomp

TI__Guru* 79441 points

Just two quick comments: The CMD_FS can fail, and this is described in the Errata note of the device. When it comes to debugging, you can manually add RF driver files to your project so that you can step into them and do debugging there.
Siri

0 stomp over 6 years ago in reply to Siri

Genius 4615 points

Thanks Siri,

I have a custom driver, and spent soooooo long debugging what I thought was crystal issues, etc.

I tried the Errata and yeah tried both my own driver and the TI-RTOS TxExample, both fail the FS command.

Here is my post on the topic:
e2e.ti.com/.../2175100

Thanks.

0 Siri over 6 years ago in reply to stomp

TI__Guru* 79441 points

If you have problems with the CMD_FS on every try, my guess is that your problem i HW related (I am a SW person so not sure what can cause this). The CMD_FS issues described in the errata will not happen very often (just wanted to make you aware of it)

BR

Siri

0 stomp over 6 years ago in reply to Siri

Genius 4615 points

Thanks,
It seems from the other thread I started that the mode I wish to use the device in is not supported on the silicon revision of our devices.

So FS fails all the time due to this reason.

0 SVS over 6 years ago in reply to Craig Easdale

TI__Genius 9705 points

Hello Craig,

On the crystal that you are using on your board, several parameters are not within the crystal specification needed for CC13xx device ( Load capacitance, ESR etc). The recommended crystals for CC13xx and CC26xx devices are listed in the following wiki page and the application report specifies detailed requirements and impact of crystal specs on the oscillator. It might be best to change to one of these recommended crystals on your board (there are some in 2016 package that you can use to swap your current crystal).

processors.wiki.ti.com/.../CC26xx_Crystals
www.ti.com/.../swra495e.pdf

Regards,

0 Craig Easdale over 6 years ago in reply to SVS

Expert 2160 points

Hi SVS,

I finally managed to get a hold of a crystal that would fit the foorprint since I had to get it from overseas. I went with the Kyocera CX2016DB24000C0WPRC1.

Still no luck though, I'm still experiencing the same problem. I'll send you a PM with the hardware design to have a look.

Sub-1 GHz

Sub-1 GHz forum

CC1310: RF_runCmd hangs in EasyLink_init() - Probably a crystal issue..?