SpaceTeddy / CC1101

driver library for Ti CC1100 / CC1101. For Arduino and Raspberry Pi
MIT License
271 stars 92 forks source link

Infinite loop after enabling RX (Raspberry Pi) #18

Closed mireckazimir closed 5 years ago

mireckazimir commented 6 years ago

Hello,

I was trying your RX_Demo on Raspberry Pi 3, but I got stuck at the beginning. I've tried running sudo ./RX_Demo -v -a3 -c1 -f868 -m100, but the only output I got was this:

CC1100 SW: Verbose option is set `'
Raspberry CC1101 SPI Library test
Init CC1100...
Partnumber: 0x00
Version   : 0x14
...done!

and the program stayed in infinite loop.

The problem is that when spi_write_strobe(SRX); is performed, the program is waiting for RX state (0x0D in MARCSTATE register). But it will never reach this value. https://github.com/SpaceTeddy/CC1101/blob/6f34280a4cd34d409b3f00087b38723b1a409785/cc1100_raspi.cpp#L547

I've tried to find out, what's happening during first iterations of while loop:

00: marcstate_rx: 0x0F
01: marcstate_rx: 0x0F
02: marcstate_rx: 0x0F
03: marcstate_rx: 0x0F
04: marcstate_rx: 0x0F
05: marcstate_rx: 0x0F
06: marcstate_rx: 0x0F
07: marcstate_rx: 0x0F
08: marcstate_rx: 0x0F
09: marcstate_rx: 0x0F
10: marcstate_rx: 0x0F
11: marcstate_rx: 0x0F
12: marcstate_rx: 0x0F
13: marcstate_rx: 0x0F
14: marcstate_rx: 0x0F
15: marcstate_rx: 0x0F
16: marcstate_rx: 0x0F
17: marcstate_rx: 0x0F
18: marcstate_rx: 0x0F
19: marcstate_rx: 0x0F
20: marcstate_rx: 0x1F
21: marcstate_rx: 0x00
22: marcstate_rx: 0x00
... (continuing with 0x00) ...

Am I doing something wrong? SPI is connected correctly, WiringPi is up to date... I am using this CC1101 module. Maybe it can be a hardware problem... maybe wrong piece.

Thank You for any help! 🙏 😄

Mirec

SpaceTeddy commented 6 years ago

Hi Mirec,

please be so kind and double check your SPI conenction. For instance, in your log file, marcstate 0x1F is not a valid value. On page 93 of cc1101 datasheet, 0x1f is not listed. can you confirm, that all registers are written correct?

20: marcstate_rx: 0x1F

thank you,

chris

mireckazimir commented 6 years ago

Hi Chris,

I've checked SPI connection and also registers right after writing into them in CC1100::begin function: https://github.com/SpaceTeddy/CC1101/blob/6f34280a4cd34d409b3f00087b38723b1a409785/cc1100_raspi.cpp#L420

This is the result:

settings that are written in set_mode() function (using cc1100_GFSK_100_kb): 0x07 0x2E 0x80 0x07 0x57 0x43 0x3E 0x0E 0x45 0xFF 0x00 0x08 0x00 0x21 0x65 0x6A 0x5B 0xF8 0x13 0xA0 0xF8 0x47 0x07 0x0C 0x18 0x1D 0x1C 0xC7 0x00 0xB2 0x02 0x26 0x09 0xB6 0x17 0xEA 0x0A 0x00 0x11 0x41 0x00 0x59 0x7F 0x3F 0x81 0x3F 0x0B

configuration read from CC1101 registers right after set_mode(): 0x07 0x2E 0x80 0x07 0x57 0x43 0x3E 0x0E 0x45 0xFF 0x00 0x08 0x00 0x21 0x65 0x6A 0x5B 0xF8 0x13 0xA0 0xF8 0x47 0x07 0x0C 0x18 0x1D 0x1C 0xC7 0x00 0xB2 0x02 0x26 0x09 0xB6 0x17 0xEA 0x0A 0x00 0x11 0x61 0x00 0x59 0x7F 0x3F 0x81 0x3F 0x0B

The only difference is in RCCTRL1 - RC Oscillator Configuration, which is correct, because 0x41 is only the reset value. Therefore I think there's no problem in SPI connection (I mean wiring). 🙁 Maybe it might have something to do with this (page 4).

Mirec

SpaceTeddy commented 6 years ago

well, it seems that the registers are written correct. It should not be an SPI issue. Your hint to the errata sheet could be right, because marcstate is mentioned there as potential infected, frequently changed register.

As a dirty test, you can bypass the

`while(marcstate

!= 0x0D) //0x0D = RX { marcstate = (spi_read_register(MARCSTATE) & 0x1F); //read out state of cc1100 to be sure in RX //printf("marcstate_rx: 0x%02X\r", marcstate); }` check and change the delay from 100us to around 10ms.

Did you start also the TX_Demo example? Does this example has the same issue?

thanks, chris

mireckazimir commented 6 years ago

After bypassing while loop, it seems okay... but when I tried to receive something (I've changed registers), I got this:

CC1100 SW: Verbose option is set `'
Raspberry CC1101 SPI Library test
Init CC1100...
Partnumber: 0x00
Version   : 0x14
...done!
Mode: 3
Frequency: 3
Channel: 0
My_Addr: 0
Config Register:
0x07 0x2E 0x80 0x07 0xC6 0x26 0xFF 0x04 0x45 0x00 
0x00 0x08 0x00 0x21 0x65 0x6A 0xC8 0x93 0x13 0x22 
0xF8 0x34 0x07 0x0C 0x18 0x16 0x1C 0x43 0x40 0x91 
0x02 0x26 0x09 0xB6 0x04 0xEC 0x2F 0x16 0x11 0x61 
0x00 0x59 0x7F 0x3E 0x81 0x3F 0x0B 
PaTable:
0x03 0x17 0x1D 0x26 0x50 0x86 0xCD 0xC0 
no bytes in RX buffer or RX Overflow!: 0xC1 
no bytes in RX buffer or RX Overflow!: 0x00 
no bytes in RX buffer or RX Overflow!: 0x00 
..... (etc.)

The positive thing is that it reacts to data sent from another transciever (in my case this little thing). Don't know, if it's something wrong with registers now. 🙁 Here is difference in registers.

Mirec