CCS/LAUNCHXL-CC1310: CCS/LAUNCHXL-CC1310

The easist way to make a new project is to start from one of the existing examples in the SDK. If you import the empty example and add new files to this you should have no issues.

"But when I tried to add some code (Even as simple as toggling DIO15, it doesn't respond to my codes.": Not sure why you didn't get this to work. Which example did you start from and exactly which changes did you make?

For F32, I have found that the method you tried works, modifying the 128 cmd file with the correct memory sizes. What happens when you debug this program? If the program doesn't work I assume that the code get stuck at a specific place in the code?

Dear Ter,

I passed that step but now I need a furher asistance for the issue below.

I would start a new thread for this, but following from here, please advise.

Hi all,

I designed 3 custom boards based on CC1310F32.

Before doing that job, I've bought one LAUNCHXL-CC13-90 with CC1190 and one LAUNCHXL-CC1310 for design referencing and testing.
Both runs well. Tested them, discovered design techniques, designed my custom PCBs, manufactured PCBs and mounted the components
with mass production manner, by stencil and smdLine processes , no hand process.

In my boards, I precisely followed RF design techniques, although the same components and PCB layouts referred.
I used a 24Mhz TSX-3225 with no comp capacitors, no any other external components, no 32Khz cyristal, no SD nor any other component.
Only a few test IO pins, SPI pins and a led. This PCB(number 1) is a simple PCB planned to play role for RF gateway.

I've powered the board, but unfortunately after digging with a pin for 8 days, I finally succeeded to compile the 'Empty' demo project in the Simplink for F32.
It was so hard to convert the demo empty project to play for CC1310F32.
I think, all the staff thought that everyone to use F128. No supplementary methods for easily migrate to F32.
I did it on CCS 10.0. (Watched over 100 videos, read hundres of pages)

But now, I can port the IO pins, toggle the led, debug the board with no any problem.

Now ready for RF process. !!

Tested my pre bought Launcpads again, set one of them as receiver, and the other as transmitter. Runs. (They run on CC1310F128)
But after converting the project to CC1310F32, the Cpu F32 runs, Led and IO ports toggle, but the receiver Launcpad doesn't get the package from my custom board.
Every parameter is the same, now I can easily switch between F128 and F32.
Every process runs well on Launchpads, but my board with F32 doesn't transmit.
I debugged the code on my board, the code reaches the transmit line, processes the transmit line and returns 'cmdStatus' as 0x3400 : case PROP_DONE_OK: // Packet transmitted successfully

But the receiver side Launchpad doesn't receive any data packet. I've tested with original Receiver project already running before. Also tried with Smart RF Studio7.
No success.
Used another custom board. Result is the same, unsuccessful.

Examined the pcb design again and again, spent 1 full day.
I'm sure the custom Hardware is OK.

Then tested my board with Smart RF Studio 7.
Packet TX and Packet RX process is unsuccesfull.

Then tried in continuous TX and RX. Now IT'S OK. !!! :) :) :)

Worked as the same dB gain with original Launchpads even better due to antenna.
My board can get the continuous signal from tansmitter, also receive signal when the Tx side sends packets, as well.
My board can send continuos TX signal with the same dB gain as demo boards. These are well.

But I can't send and receive Packet TX, and Packet RX.
Every config is the same int both side.

Then I discovered the 1743 pages of CC1310 Technicial Manual.

Why my F32 board can't tansmit and receive packets.

I tried every option in Smart RF Studio7. No any result.

I suspected from oscillator configuration but I see that Smart RF Studio7 configures all the parameter precisely.

What do you advise me?

Could you please supply any surely running simple RF project prepared and tested especially on CC1310F32. ?

Sorry for my writing in every detail so long.
Because I saw in the forums that, concurrent answers and replies cause to waste time.
So I have written every detail in my first text.

Best Regards
Feza AKSOY

For modifying a F128 project to F32, only some small changes have to be done. See https://dev.ti.com/tirex/content/simplelink_cc13x0_sdk_4_10_01_01/docs/proprietary-rf/proprietary-rf-users-guide/proprietary-rf-guide/custom-hardware.html#cc13x0-f32-f64

SmartRF Studio doesn't use the flash, it uploads only some code to RAM. Meaning that for SmartRF Studio the flash size doesn't matter. SmartRF Studio is also what I normally call "known good" software. When starting testing it's recommended to start by using known good HW and test SW or the other way around to easier find out if SW or HW is the issue. 

Meaning that you should first get your board working with SmartRF Studio before you try to run code on them. 

I suspect that you have a frequency offset between the RX and TX board. Do you have a spectrum analyzer to do measurements with? 

Dear Ter,

Thanks for your kind and quicky reply.

Moving from 7x7 to 4x4 does not affect RF. The typical issue here is undefined pins that cause the code to halt in the PIN_init() part of the board setup. If you have managed to blink a LED your porting to a 4x4 works. 

The same with the port from F128 to F32. This is not affecting RF and if you have managed to blink a LED you have managed to do this correctly.

We don't have any example code for a F32, 4x4. The main reason for this is that we don't have any boards to test this on. To make a software example a board file is required and this file will be HW dependent. 

Not clear what you mean by only continuous RX/ TX was possible. Does that mean you see that the RSSI on the RX side change when you TX something? If you send packets with SmartRF Studio, do you see that the RSSI line (using cont. RX with SmartRF Studio) has some time variance?   

I would also recommend requesting a design review through https://www.ti.com/tool/SIMPLELINK-SUB1GHZ-DESIGN-REVIEWS since this could indicate a hardware issue. 

This: https://dev.ti.com/tirex/content/simplelink_cc13x0_sdk_4_10_01_01/docs/proprietary-rf/proprietary-rf-users-guide/proprietary-rf/cc1101-migration.html could be to some help when you are used to work with CC1101.

Not clear what you mean by only continuous RX/ TX was possible. Does that mean you see that the RSSI on the RX side change when you TX something? If you send packets with SmartRF Studio, do you see that the RSSI line (using cont. RX with SmartRF Studio) has some time variance?   

Answer:

I set my board as Continuous TX in SmartRfStudio7 and set another known good Launchpad in continuous Rx mode.

When I start my board as Continuous Tx, I can see a RSSI -30db on the Rx side.

Also when I swithch the Txmode to 'Packet Tx', I can see RSSI -30dB beats on the Rx side , as well.

I can also observe the same results if I switch the Tx and Rx sides (Boards). Hardwares operates well.

I think the problem is related with Packet transmission protocol.

I checked every detail. It seems an overlooked item is present.

Can you advise a ccfg file for default Radio configurations. Maybe I can hardcode it.

Or any other advice please. I'm chashed. I can't move now.

Thanks

As I wrote:

I would also recommend requesting a design review through https://www.ti.com/tool/SIMPLELINK-SUB1GHZ-DESIGN-REVIEWS since this could indicate a hardware issue. 

Looking at your schematic, what is the setting SET_CCFG_MODE_CONF_SCLK_LF_OPTION set to in your CCFG.c file? This should be set to 0x03 when you don't have an external 32 kHz xtal. 

Yes, I did it as follows

//#####################################

// Clock settings
//#####################################

#ifndef SET_CCFG_MODE_CONF_SCLK_LF_OPTION
// #define SET_CCFG_MODE_CONF_SCLK_LF_OPTION 0x0 // LF clock derived from High Frequency XOSC
// #define SET_CCFG_MODE_CONF_SCLK_LF_OPTION 0x1 // External LF clock
// #define SET_CCFG_MODE_CONF_SCLK_LF_OPTION 0x2 // LF XOSC
#define SET_CCFG_MODE_CONF_SCLK_LF_OPTION 0x3 // LF RCOSC
#endif

And, I need to know why the 32Khz external crystall is needed for normal RF operation.

As an information, I saw that the original launchpads uses 32Khz external crystals in demo rFPacketTx exzpmle as I short wired crystal pins, the RF tx process is halted.

My board produces 0x3400 as Rf status result for remembering my text.

My board can produce good Power output at 868Mhz, but the receiver side cannot decode any meaningful packet data still.

The last picture you tried to upload does not show. Use the "Insert/ Edit Media" button. 

"My board can produce good Power output at 868Mhz": Have you actually measured the output power or are you basing this on received RSSI? If the latter you will not be able to see if the TX side gives the wanted performance, just that you get something out.

The 32 k is not used by RF. The reason I ask is if the rfPacketRX example is used, a LF clock is needed to wake the radio up every x time units. 

The schematic look ok. 

The DCDC part of  the layout does not look ok. See "DC/DC Regulator" in https://www.ti.com/lit/pdf/swra640 

We have seen before that the sensitivity is impacted by poor DCDC layout. To see if this cause what you are seeing, turn off the DCDC in the CCFG.c file (use the internal GLDO)

You said;

The schematic look ok. 

The DCDC part of  the layout does not look ok. See "DC/DC Regulator" in https://www.ti.com/lit/pdf/swra640 

Yes, you're right, I'll take care that for further revisions, but anyway, I'think my design is  %60 efficient. As I said before, if I send Continuons TX signal by SmartRfStudio, the receiver side gets at least -30dbm RSSI, it may be best of bads anywwhow the design is poor. Why can't I catch even 1 packet of data form 1 meters distance?

We have seen before that the sensitivity is impacted by poor DCDC layout. To see if this cause what you are seeing, turn off the DCDC in the CCFG.c file (use the internal GLDO)

I switched the system to GLDO, the result is the same, unsuccesful..

Now I have a plan plan for trying 2 methods.

The two main hardware difference between real Launchpad and my board are external 32Khz and External Flash.

I disabled the external flash completely. I will produce 32Khz output from launchpad digital output pin and wire this signal as external 32Khz for my board.

If it fails, I will try to regenerate Radio configuration parameters step by step with old conventional style as I had done it for CC1101 interface 7 years ago.

If you catch any subject or if you have any further advice, it will be appreciated

Best Regards

Feza AKSOY

When you have the custom board in TX it seems that it sends something but for me to remote debug these boards it would be very helpful to see the TX spectrum. 

It sounds like you have worked with RF for some years, but you don't have access to any RF instruments? Is possible to borrow/ rent a spectrum to do some measurements? 

Yes, we worked with RF for some years, but we used pre assembled mini stamp boards supplied from a vendor, we only interfaced via SPI, configured and used without any problem.

This time, this is the first attempt to go into the real RF world, we are beginner. I'll supply a spectrum analyser soon. But now, I think my problem is related with protocols or RF configuration when switch the board to F32.

Anyway, I insistly request a simple RF demo project known good workink on F32 for test.

Could you please ask from your customers or members who suceeded it with CC1310F32 before or 

could you please link me any forum thread related this issue, maybe I had missed. I have readen hundreds of forum threads about CC1310 but maybe you can direct me any which can inspire me to solve the issue.

Best Regards

Feza AKSOY 

Hi TER,

After working a full weekend approximately 30 hours, I fortunately solved the issue.

I saw that my hardware design and all mechanics work well.

When I set my board side frequency to 867.920 by shifting down 80Khz, every issue is solved suddenly.

Now I can get RSSI -20dBm and all the packets can be transmitted and received successfuly.

Launchpad Side: 868.000 Mhz,  my board side 867.920 Mhz

Eventually, I solved my issue. But now I wonder why the 80Khz frequency shift is necessary on my Pcb board with F32 while the original Launchpads with F128 don't need ??

I'm waiting for your comments.

Hi TER,

After working a full weekend approximately 30 hours, I fortunately solved the issue.

I saw that my hardware design and all mechanics work well.

When I set my board side frequency to 867.920 by shifting down 80Khz, every issue is solved suddenly.

Now I can get RSSI -20dBm and all the packets can be transmitted and received successfuly.

Launchpad Side: 868.000 Mhz,  my board side 867.920 Mhz

Eventually, I solved my issue. But now I wonder why the 80Khz frequency shift is necessary on my Pcb board with F32 while the original Launchpads with F128 don't need ??

I'm waiting for your comments.