• State
  • Locked Locked
  • Replies 6 replies
  • Subscribers 53 subscribers
  • Views 680 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Migration from CC1101 to CC430f5137

Daniel Berenguer
Expert 2185 points
Other Parts Discussed in Thread: CC1101, ENERGIA, SIMPLICITI

I've been working with CC1101's for a while using an external MCU and would like to migrate to a pure CC430 solution. I've been able to communicate with the Chronos watch from my cc1101-based modules in the past by means of OpenChronos. Everything has been working fine and found the CC430 to be a nice evolution of my current design. However, I can no longer base my developments on OpenChronos since I need something much more compact and without all those explicit references to the Chronos hardware. In a first moment, I want to communicate with my current CC1101 design from a CC430 board without all the exsting bsp+mrfi code used in the Chronos.I expected to create a simple code capable to do this at least.

This is the part of the code where the CC430 transmits a packet:

void transmit(unsigned char bytes[], unsigned int length)
{
  char status;

  // Wait for radio to be in idle state
  status = radio.strobe(RF_SIDLE);
  while (status & 0xF0)
  {
    status = radio.strobe(RF_SNOP);
  }

  // Clear TX FIFO
  status = radio.strobe(RF_SFTX);

  if(length <= 64)
  {
    radio.writeTXBuffer(bytes, length); //Write bytes to transmit buffer
    status = radio.strobe(RF_STX); //Turn on transmitter
  }

  status = radio.strobe(RF_SNOP);

  // Wait for transmission to finish
  while(status != 0x7F)
  {
    status = radio.strobe(RF_SNOP);
  }

  radio.strobe(RF_SIDLE); // Put radio back in idle mode
  return;
}

The issue is that, if I set PKTCTRL0 to variable packet length and CRC (0x05), the above function stalls on " while(status != 0x7F)" whilst waiting for the transmission to end. Otherwise, if I sent PKTCTRL0 to infinite length or fixed length the function runs OK, even if I'm not able to see anything is transmitted or not at this moment. The fact is that my current CC1101 board does not receive anything.

I'm thinking that working with this CC430 is more complicated than simply controlling a CC1101 via SPI. Have I maybe to enable some hardware option even before setting the RF config registers?

  • 0
    TI__Guru* 86321 points

    Hi Daniel

    I do not understand why you wait for the radio to underflow (status byte = 0x7x). When you use variable packet length mode the length byte must be the first byte of the payload written to the TX FIFO: For example, if your data are 1, 2, 3, 4, 5, you must write 5, 1, 2, 3, 4, 5 to the TX FIFO. After strobing TX the radio will send the data and then automatically go back to IDLE (if TXOFF_MODE = IDLE).

    To determine if the radio is done sending the packet you can either poll MARCSTATE to see if the radio is back in IDLE, or you can use an interrupt. The radio core provides interrupt signals to the radio interface. There are three programmable output signals GDO0, GDO1, and GDO2 that can also be routed to pins as well as hardwired output signals going into the interrupt logic.

    Please see http://www.ti.com/lit/zip/slac525 for simple RF examples using the CC430.

    BR

    Siri

  • 0 in reply to Siri
    Expert 2185 points

    You are right. This was in fact one of my latest tries after checking marcstate against TX, and  RXTX_SETTLING. Checking marcstate against TX, and  RXTX_SETTLING is at least what I did after switching to STX on the CC1101. In any case, checking against IDLE makes no difference (TXOFF_MODE = IDLE). The process stills hangs on the while loop.

    I still need to talk to the guys from the Energia project (Did I say that I'm using energia?) to see if the precompiler is initializing the hardware in some way (I'm also unable to communicate through the UART). BTW, if we get to add support for the CC430 from Energia this processor could become very popular among the open community.

  • 0 in reply to Daniel Berenguer
    TI__Guru* 86321 points

    I do not have other suggestion than following the code examples on the web and then, when you get them up and running, changes the code step by step, to fit your application.

    All the reference SW for the CC430 is written by the MSP430 and not the LPRF team so it might be a good idea to try to contact them for support as well.

    BR

    Siri

  • 0 in reply to Siri
    Expert 2185 points

    I've tried the sample code from Variable_LT_FIFO. The program now seems to run fine except that my CC1101 nodes do not receive anything from the CC430 board. I've set the same RF settings used by these nodes and also the ones calculated by rfstudio. I'm now going to order some CC430 boards more to see if I can at least communicate between them.

    Thank you very much for your time.

  • 0
    Genius 3370 points

    SimpliciTI has support for the CC430EM and is more barebones than anything specifically written for the Chronos. In fact, I think the Chronos code was built up from SimpliciTI.

  • 0 in reply to Timothy Barr
    Expert 2185 points

    Thanks Tim, but I've finally been able to write a minimum code that works. I only had to fix some timing issues.