• State
  • Locked Locked
  • Replies 8 replies
  • Subscribers 79 subscribers
  • Views 1209 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

CC430 frequency shift when powered after progam

Tristan Weydts
Prodigy 90 points
Other Parts Discussed in Thread: CC430F5137

Hello,


For a project I am using a wireless readout of several sensors and transmitting the data wirelessly to a second CC430, which transfers it to a pc via UART-USB.

The microcontrollers I use are CC430F5137.

The problem is the following: I set the frequency to 435 MHz, which is the frequency for which my antennas and balun are designed. When I program the code to the microcontroller with the debugger, the program works fine. But, when I detach the debugger and power the board again, the receiver does not get its data anymore. This happens when powering by the same debugger, battery, or USB with voltage regulator. I am using a spectrum analyser now. I see that when everything is working ok, the frequency is indeed 435 MHz. But when I power the board without reprogramming it, I see frequencies of 439 MHz, 443 MHz and 437 MHz with the spectrum jumping between them randomly. Thus my receiver does not get any data.


The first time I noticed this, I was using code someone else wrote and he had changed VCore to 1. Changing it to 3 (the default) fixed the problem for a while. But now I am using more sensors and this VCore fix is no longer working. I think however that there is a larger problem at hand, maybe an oscillator stability problem? I have recently changed the crystals on the board and the load capacitances to all new ones but this has not fixed the problem.


Has anyone seen something similar and what would be a way of finding the source of this problem?

Kind regards,

Tristan

  • 0
    TI__Guru**** 207137 points
    Tristan,

    It sounds like your Vcore is unstable and perhaps not being set correctly. What frequency is the CC430F5137 operating at? When you step up the Vcore to 3 do you take the steps one at a time or all at once? The default Vcore value is zero. Is the standard 470 nF capacitor connected from the Vcore pin to GND?

    Regards,
    Ryan
  • 0 in reply to Ryan Brown1
    Prodigy 90 points
    Hi,

    The CC430F5137 is operating at 8 MHz in this application. I use the 'hal_pmm.c' library to change the VCore, so it happens in steps of 1 with all the correct steps as suggested by TI. I do have a 470nF capacitor between Vcore pin and GND.
    I seem to have found a (temporary) solution to my problem, which is to set UCSCTL6 &= ~XT2OFF;
    This leaves XT2 always on, even when the RF core is in LPM. It is not the most energy efficient solution but works for now.

    This seems to me to indicate that the crystal is slower to startup than expected every time I need to send data. And maybe this would explain why Vcore level can influence it by giving the crystal a little bit more/less power. But it seems it was still on the edge of being unstable.

    If you have any suggestions on how to fix this problem properly, please do.
    Thank you very much,
    Tristan
  • 0 in reply to Tristan Weydts
    TI__Guru**** 207137 points
    Hello Tristan,

    If operating at 8 MHz you should only have to step up to Vcore1 for maximum energy efficiency, but levels 2 and 3 work as well. Are you using a TI-supplied EVM board or a custom board? You're temporary solution has me likewise thinking that something is wrong with the crystal initialization. Do you perform a delay to ensure that XT2 has stabilized before beginning operation?

    Regards,
    Ryan
  • 0 in reply to Ryan Brown1
    Prodigy 90 points
    Hello,
    I am using a custom board (one that someone before me has designed and used throughout his entire PhD, and which I have quite some experience with as well).
    I have a 100ms second delay as the second thing I do after power up (only turning off the watchdog timer is done before that). After this delay I set the clock speed. If you mean to put a delay before sending a new packet over RF every time, that is not in the code at the moment.

    Kind regards,
    Tristan
  • 0 in reply to Tristan Weydts
    TI__Guru**** 207137 points

    Tristan,

    I meant more like this:

      // Loop until XT1,XT2 & DCO stabilizes
  do
  {
    UCSCTL7 &= ~(XT2OFFG + XT1LFOFFG + DCOFFG);
                                            // Clear XT2,DCO fault flags
    SFRIFG1 &= ~OFIFG;                      // Clear fault flags
  }while (SFRIFG1&OFIFG);                   // Test oscillator fault flag

    But I'm not sure if that will do you any good.  You can try placing a delay before sending a RF packet but I don't have much confidence in this approach either.  I just know that debugger mode forces slower operation and that could be the difference between your two instances.  XT2 is a HF crystal and can consume a decent amount of current, can you confirm that the power supply is able to give the amount of current needed?

    Regards,

    Ryan

  • 0 in reply to Ryan Brown1
    Prodigy 90 points
    I had tried that piece of code before, but it got the program stuck in the loop because XT1LFOFFG never clears up.. So i went with the delay by just using __delay_cycles instead.
    Having the debugger run the program at a slower pace (or even removing a true low power mode?) seems to make sense given the symptoms I see.
    I tried powering the board with 2 AA batteries, via USB with a FTDI voltage regulator to 3.3 V and with the debugger at 3.6 V (I am using an MSP-EZ430U debugger/programmer). I recall that sometimes the system worked better with the 3.6 V, but it was still not reliable enough to use in a real measuring environment. I would think that all these power supplies can deliver enough current for one crystal?
    Kind regards,
    Tristan
  • 0 in reply to Tristan Weydts
    TI__Guru**** 207137 points

    If that's the case then the delay should follow setting the clock, but you should reference some other E2E posts to figure out why XT1LFOFFG never clears.  I still think the answer lies somewhere in the XT1/XT2/DCO initialization.

    Tristan Weydts said:
    I would think that all these power supplies can deliver enough current for one crystal?

    They should but one never can be too sure.

    Regards,

    Ryan

  • 0 in reply to Ryan Brown1
    Guru 227245 points
    "If operating at 8 MHz you should only have to step up to Vcore1 for maximum energy efficiency, but levels 2 and 3 work as well. "
    That's correct, but IIRC for RF operation PMMCOREV2 is the minimum, independently of the CPU frequency.

    It's possible that the oscillator gets unstable due to unstable power supply during the increased supply current during transmit. What if you attach a big storage capacitor to VCC right at the chip?

**Attention** This is a public forum