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...) |
|||
| Line 1: | Line 1: | ||
| − | |||
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 13: | ||
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. | |
Revision as of 06:39, 7 February 2008
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.
