• State TI Thinks Resolved
  • Locked Locked
  • Replies 8 replies
  • Answers 2 answers
  • Subscribers 17 subscribers
  • Views 1600 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.

CC1110-F32 frequency problem

Vasily Stepanov
Prodigy 65 points
  Our chip's program works with external crystal oscillator (27MHz) - the clock (13.5MHz) is derived from it by division via special registers, the Baud (should be 38400) is derived from the clock and one of the GPIO CC pin is toggled once in half a second (derived from the Timer 1). These frequencies aren't changed in any way in the program (a very simple program for chip evaluation).
  Once in a couple of days or hours we find that CC jumps to work from another frequency (it has been working for hours as it should have been till this happens) - we get the Baud 19200, pin toggle once in a second, but the program hasn't been changed and when can see on a scope that the crystal continues to work with the same frequency (27MHz).
  Reset brings the CC back from this state (Baud 19200) to normal state (Baud 38400).
  In addition, we work in the -20C to 70C temperature range.
 We have encountered the problem in two CC chips.
Have anybody encountered this problem?
  • 0
    Prodigy 20 points

    Hi! We have exactly the same problem: our CC1110F8 scales down to half the clock frequency once in a while and scales up to the old frequency some time later. This does not affect radio, so we do also think it is not the Quartz' fault (26Mhz). We realized this effect only because we have used UART and suddenly got half the Baudrate. We have observed, however, that these events happen whenever there is a EMV perturbation (someone switches on or off the light  in the lab). These events seem to perturb the chip somehow. We have not yet found a solution.

    Axel

  • 0
    Prodigy 20 points

    I had the same problem. I was investigating why it happens and I find the cause and the solution for my case.

    The problem was that the system clock speed sometimes was a half the correct frequency. I realized too that using SmartRF it detected as if I was using the CC1111Fx. I read PARTNUM register and it was read as 0x01 CC1110Fx or 0x11 CC1111Fx alternately. It does really estrange that the value of a read only register changes but it was what happened.

    In my case the cause was that the reset circuit was wrong and it caused that the value of PARTNUM was wrong. However, I cannot understand why it happens.

    It is not necessary to put anything connected to RESET_N because it has an internal 20k pull-up

  • 0
    TI__Expert 3370 points

    Hi Vasily.

    I haven't heard of this type of problem before.

    But it would be nice if you could confirm this is with the latest silicon revision of CC1110, i.e. VERSION == 0x03 (aka revision D)? You can check this e.g. with SmartRF Studio or in the debugger of IAR EW8051.

  • 0 in reply to Gabriel Moreno
    Prodigy 20 points

    we can reproduce exactly the same behavior with our CC1110F8 devices. After an external reset, the PARTNUM register has changed and the clockfrequency drops to 13Mhz instead of 26Mhz. Our workaround is, to immidiately enforce a watchdog reset as soon as we recognize an external reset (via SLEEP register). After a watchdog reset, the PARTNUM register is always correct.

     

    Axel

  • 0 in reply to Axel10093
    TI__Mastermind 21125 points

    Guys,

    The CC1110 is very sensitive to noise and glitches to the reset line. Please note the following from the datasheet:
    - RESET_N low width: minimum 250 ns (from table 19)
    - Chapter 6.11.1 Filtering of RESET_N pin

    I would strongly suggest that you add one of these filters to your designs as this will prevent glitches that are shorter than 250 ns.

    Rgds,
    Kjetil

  • 0 in reply to Kjetil
    Prodigy 20 points

    I had the recommended RC filter mounted and the reset time was much higher than 250ns. In fact that was the problem. I had not read about power on reset before I design my PCB. I mounted a pull-up resistor with a capacitor between RESET_N and GND. The time constant was too high. That reset condition was what cause the wrong PARTNUM value on power-on.

    In my case, the external reset during power-on was the cause of the problem.

    Regards,

    Gabriel Moreno

  • 0 in reply to Gabriel Moreno
    TI__Mastermind 21125 points

    Hmm..

    Not a HW expert so can't really comment on your findings. All i can say is that a too short reset pulse may be recognized but not fully reset the chip. The behavior you describe might be one of the side effects. Anyway, the workaround described above will always result in a safe and full reset:

    Our workaround is, to immediately enforce a watchdog reset as soon as we recognize an external reset (via SLEEP register). After a watchdog reset, the PARTNUM register is always correct.

    Rgds,
    Kjetil

     

     

  • 0 in reply to Kjetil
    Prodigy 65 points

      Hi,

    We have found a way to regeneerate the problem at will. If we turn on/turn off the DC power supply that is connected only via common ground to the set-up we get the frequency jump. I've heard that it works with soldering iron and lamps :)

    The problem was indeed the short reset. We had debug/CC burn cable attached during the tests which was long enough in order to work as an antenna. We have seen the waves on the line with a scope.

    During a test in which we have connected a function generator to the reset line we sent short pulses. With pulses 40 ns and shorter we have encountered our problem (the frequency jump).

    Since we disconnected the cable during tests we haven't encountered the problem.

     

    Vasily