• State
  • Locked Locked
  • Replies 3 replies
  • Subscribers 54 subscribers
  • Views 328 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.

cc1111 Malfunction Problem

Fahd Albinali
Intellectual 490 points
Other Parts Discussed in Thread: SIMPLICITI

Hi,

We are using cc1111 on one of our products that provides emergency service. We encountered a very problematic situation today with the chip acting strangely with a customer. The cc1111 is running simpliciti, upon reception of a specific signal, it sets pin 0_1 high then low which activates a phone call on a phone line.

We got a call from our customer that the device is activating continuously, I had to go to the customers house and tested the device and noticed the following:

- Pin 0_1 was showing a toggling pattern which is initiating the call. This pattern happens because of setting a flag ONLY upon receiving a specific simpliciti packet and it gets set back to 0 immediately after the pin toggling is done. The only way for this to happen continuously if the device was actually receiving something.

- I tested if I am seeing any packets in the air and verified nothing is being transmitted using a sniffer with another device

- cc1111 frequency was significantly high, evident from how certain LED patterns are showing and evident by how unplugging the device gets detected very fast (while it should have taken 5 minutes from unplugging power cord when running on battery). The mcu was running too fast which. This also evident because we stopped receiving communication from the device a few hours earlier which happens over GSM. Basically, cc1111 clock got messed up and therefore communication with the GSM modem also stopped.

- unplugging the device from the wall causes it to run on battery which resulted in the toggling of pin 0_1 to stop. So when running on battery the device stopped exhibiting this pattern

- I have not seen this behavior except on 1 device and reseting the mcu, caused the device to go back to function normally

- Our code size is quite large and we have very little space on the device but did not encounter that behavior before

- The home where the device was installed was relatively warm and humid not but board did not seem to be too hot and resetting it got things working again

Any help here will be highly appreciated because this is a very critical application? Is it possible that this is a bad unit, is there a way to test that? What would cause the clock to drift quite dramatically it seems and since that happened is it possible that simpliciti will start to malfunction as it did? Last, it seems that supplying power from the battery stopped the toggling but packets were still not being received, but obviously it made a change? Do you think it is a power supply issue/noise getting generated? Thanks for the help.

  • 0
    TI__Guru* 86241 points

    Hi

    The only thing I can think of is noise on the reset pin causing an incomplete reset. The RESET_N pin is sensitive to noise and can cause unintended (and incomplete) reset of the chip.

    To avoid this an external RC filter with values 1 nF and 2.7 k should be placed close to the RESET_N pin. When doing this, the RESET_N low width will be longer than 250 ns (the shortest pulse that is guaranteed to be recognized as a reset pin request.)

    BR

    Siri

  • 0 in reply to Siri
    Intellectual 490 points

    Hi,

    I agree that this seems like a reset pin issue because we had problems before. I just need to get your thought based on the following:

    In the hardware, we initially had an RC filter of 1.5k and .1uF  (100nf) on reset line, 40k pullup after filter.   This however resulted in failure to execute program code in ~5% of power cycles. So, we ended up removing it because the problem went away when we did that. The length of trace after filter is .3", length before filter is 1.4".  The design has a full ground plane (4 layers). 

    Is there a reason why the filter we had before would result in the odd behavior of the code not running properly? Do you still recommend the 1nF and 2.7k given the above? Thanks and I appreciate your prompt feedback since we have many customers with the units and we need to make a quick decision on the next steps to eliminate the problem.

    Thanks.

    Fahd

  • 0 in reply to Fahd Albinali
    TI__Mastermind 39860 points

    2.7 kohm and 1 nF RC filter is recommended. We have used this filter for years without issues. 1.5 kohm and 100 nF RC filter will give a significantly different time constant and might explain why the filter resulted in "odd behavior of the code not running properly"