Raspberry Pi freezes while starting with CC1101

[dstolpmann]

Hi,

I have got a problem with my Raspberry Pi (Model B 512MB) and the CC1101 module from Pollin Electronic (http://www.pollin.de/shop/dt/MjQ3OTgxOTk-/Bausaetze_Module/Module/Mini_Funkmodul_CC1101_868_MHz_Sende_Empfangsmodul.html). The Raspberry freezes (gets extremely slow) after starting the Homegear service. This only happens if I configure the CC1101 module in the physicalinterfaces.conf. It seems to be similar to this: https://forum.homegear.eu/viewtopic.php?&t=264.

I have build my circuit on a breadboard and I figured out that everything works fine if I disconnect the interrupt wire for a couple of seconds and then reconnect it. After this I can communicate with a Homematic light switch without issues and even rebooting the Raspberry is not a problem, so it seems that the CC1101 module is not correctly initialized.

I installed my Raspberry as follows:

1. I created a SD-Card using this image: http://homegear.eu/downloads/rpi_homegear_wheezy_20150209.zip

2. I booted the Raspberry, logged in via SSH as pi and waited for the install script to complete.

3. I edited /etc/homegear/physicalinterfaces.conf with this result:

   [HomeMaticBidCoS]
   id = My-CC1101
   default = true
   deviceType = cc1100
   device = /dev/spidev0.0
   responseDelay = 100
   interruptPin = 0
   gpio1 = 23

4. After this the Raspberry froze while I did a sudo /etc/init.d/homegear restart at Info: Loading family module mod_homematicbidcos.so. I solved it by unplugging the interrupt wire for a short time.

5. I tried to change the configuration with raspi-config. I did a sudo poweroff and rebooted the Raspberry by unplugging the power after every step:

   A. Turn Device Tree on
   B. Turn SPI on
   C. Turn Device Tree off
   D. Turn SPI off

   The Raspberry froze at every boot and unplugging the interrupt wire for a short time was the only solution. Except in case D, where the Raspberry froze again after I reconnected the interrupt wire.

I did this today after having the same problem with a previous installation, so everything is up to date.

Regards,
dstolpmann

[cmallas]

Hi,

we couldn't reproduce this error.

D sounds reasonable because when the SPI is turned off, the interrupt handler is (repeatedly?) called but can't do its job and doesn't terminate quickly. It might fail "telling" the CC1101 to reset the INT signal to "High" via SPI.

The rest also looks like a freezing or repeatedly called driver/IRQ handler. Have you measured the Signal at the INT pin (High/Low) at booting? It should remain High until the CC1101 really "wants to tell you something" after being configured. You might try pulling the signal up with a resistor, say 10kOhms, or use another CC1101 module.

Best regards
Christian

[dstolpmann]

Hi,

thank you for your reply but using a 10k pull-up resistor does not help. I also tried to use a pull-down resistor with the same result.

I have no oscilloscope or logic analyzer but I tried to measure the logic level with a multimeter.

At the beginning (right after plugging in the power) I measured 1.63V, so there was probably an alternating signal at the interrupt pin. This remains until I unplugged the wire from the Raspberry. Then the voltage began to wobble and after some seconds it stabilized itself at 3.3V. Then it was save to plug the wire back into the Raspberry and the voltage stayed at 3.3V.

I have only one module, so I can not try another one.

Kind regards,
dstolpmann

[hfedcba]

Hey,

if you like, you can send your module to us, then we can take a look at it. The problem is definitely a hardware problem.

Cheers,
Sathya

[dstolpmann]

Hi,

sorry for my late reply and thank you very much for your help.

I think I found something quite interesting in the data sheet of the CC1101 (http://www.pollin.de/shop/downloads/D810257D.ZIP). In section 26 (page 61) there is this part:

The default value for GDO0 is a 135-141 kHz clock output (XOSC frequency divided by 192). Since the XOSC is turned on at power-on-reset, this can be used to clock the MCU in systems with only one crystal.

I have measured the output of my module on the GDO0 pin with a friend’s logic analyzer and there is indeed a 135 kHz signal on it. It seems to me that Homegear sets an interrupt handler for this pin before initializing the CC1101. Because of the high frequency the Raspberry Pi is busy with the interrupts and can not do anything else.

While this theory sounds logical to me the question is why I (and maybe the guy in the thread I mentioned in my first post) seems to be the only one with this issue.

Regards,
dstolpmann

[oli-arborum]

Hi,
I looked on the output of GDO0 with an analog oscilloscope.
I can confirm a signal on GDO0 before initializing the RF module.
But in my case after starting Homegear this state remains until I disconnect GDO0 from GPIO and reconnect it. After that it all seems to work correctly. I think this is exactly the behavior dstolpmann described in #232 (comment)
It seems not to fix itself when waiting long enough.
If I start Homegear with GDO0 disconnected from GPIO I see the signal on GDO0 disappearing after RF module initialization.

Regards,
oli-arborum

[hfedcba]

I changed the source code of Homegear to first initialize the TICC1101 and then set the GPIO direction to "input". Does that change anything? If that doesn't work, there is actually not much more we can do...

Cheers,

Sathya

[dstolpmann]

Hi Sathya,

I tested the current nightly build for Raspbian 7. It has the same problem, but I can see in the log that the GPIO is set after the SPI communication.

Maybe the module is not ready when the GPIO is activated and there needs to be a delay?

I would like to play around with the code, but I have not figured out how to compile it. I look forward for the tutorial you announced in #238.

Regards,
dstolpmann

[oli-arborum]

Sathya, In which commit did you change the order of CC1101 initialization and setting GPIO direction to input?
Thanks,
oli-arborum

[dstolpmann]

Hi,

it seems to be this one: Homegear/Homegear-HomeMaticBidCoS@a9c89b7

Regards,
dstolpmann

[oli-arborum]

Oh, I didn't look 13 days back in the commit log...