Difference between revisions of "New CCxx00 Platforms Troubleshooter"
m (New page: 1. Are you getting a SplitControl.startDone() event? ** There are lots of while() loops in BlazeInitP. Is execution getting locked up in one of those? This could indicate a hardware pro...) |
|||
| (One intermediate revision by the same user not shown) | |||
| Line 1: | Line 1: | ||
| + | == Automatic Gain Control Settings == | ||
| + | The automatic gain control registers stored in the CC1100.h and CC2500.h files need to be modified for use in your particular platform or application. Use [http://focus.ti.com/docs/toolsw/folders/print/smartrftm-studio.html SmartRF Studio] to calculate: | ||
| + | * AGCCTRL2 | ||
| + | * AGCCTRL1 | ||
| + | * AGCCTRL0 | ||
| + | |||
| + | If you do not set your automatic gain control registers correctly, the radio will always see the channel as "in use". This means you will never be able to transmit. | ||
| + | |||
| + | The AGCCTRL* registers vary based on data rate, CC1100 vs. CC1101, etc. | ||
| + | |||
| + | |||
| + | == Basic Troubleshooting == | ||
1. Are you getting a SplitControl.startDone() event? | 1. Are you getting a SplitControl.startDone() event? | ||
| − | + | * There are lots of while() loops in BlazeInitP. Is execution getting locked up in one of those? This could indicate a hardware problem. When debugging this part, I typically surround the while loops with Leds.set(xyz) statements to read the error code off the leds and see which while() loop is causing the lock up: | |
call Leds.set(1); | call Leds.set(1); | ||
while(...); | while(...); | ||
call Leds.set(0); | call Leds.set(0); | ||
| − | + | ||
call Leds.set(2); | call Leds.set(2); | ||
while(....); | while(....); | ||
| Line 14: | Line 26: | ||
2. Are you able to get an AMSend.sendDone() event back? | 2. Are you able to get an AMSend.sendDone() event back? | ||
| − | + | * BlazeTransmitP will not transmit if it sees the channel is not clear. | |
There have been quite a few cases where the channel is definitely clear but the hardware doesn't think so. This is most likely due to LNA settings in AGCCTRL2, and RSSI threshold settings. Try lowering the gain of the LNA to allow the radio to think the channel is clear. | There have been quite a few cases where the channel is definitely clear but the hardware doesn't think so. This is most likely due to LNA settings in AGCCTRL2, and RSSI threshold settings. Try lowering the gain of the LNA to allow the radio to think the channel is clear. | ||
3. Is the RxInterrupt being fired inside of BlazeReceiveP? | 3. Is the RxInterrupt being fired inside of BlazeReceiveP? | ||
| − | + | * If the RxInterrupt is not firing with another CC1100 transmitter nearby, you could be on the wrong frequency or the other transmitter isn't working properly. | |
| − | + | * Make sure IOCFG2 is configured to be 0x1, which is an RXFIFO threshold indicator for the receive branch. | |
Latest revision as of 10:54, 8 May 2008
Automatic Gain Control Settings
The automatic gain control registers stored in the CC1100.h and CC2500.h files need to be modified for use in your particular platform or application. Use SmartRF Studio to calculate:
- AGCCTRL2
- AGCCTRL1
- AGCCTRL0
If you do not set your automatic gain control registers correctly, the radio will always see the channel as "in use". This means you will never be able to transmit.
The AGCCTRL* registers vary based on data rate, CC1100 vs. CC1101, etc.
Basic Troubleshooting
1. Are you getting a SplitControl.startDone() event?
- There are lots of while() loops in BlazeInitP. Is execution getting locked up in one of those? This could indicate a hardware problem. When debugging this part, I typically surround the while loops with Leds.set(xyz) statements to read the error code off the leds and see which while() loop is causing the lock up:
call Leds.set(1); while(...); call Leds.set(0); call Leds.set(2); while(....); call Leds.set(0);
2. Are you able to get an AMSend.sendDone() event back?
- BlazeTransmitP will not transmit if it sees the channel is not clear.
There have been quite a few cases where the channel is definitely clear but the hardware doesn't think so. This is most likely due to LNA settings in AGCCTRL2, and RSSI threshold settings. Try lowering the gain of the LNA to allow the radio to think the channel is clear.
3. Is the RxInterrupt being fired inside of BlazeReceiveP?
- If the RxInterrupt is not firing with another CC1100 transmitter nearby, you could be on the wrong frequency or the other transmitter isn't working properly.
- Make sure IOCFG2 is configured to be 0x1, which is an RXFIFO threshold indicator for the receive branch.
