Howdy,
I know I've already posted this problem on a few other forums but they keep telling me that they aren't the right ones so I thought I would try this forum. I've been working with two CC430F6137 trying to understand the basics and learning how to make them run fast. The issue I keep having is when using the example Fixed_GT_FIFO that is given on the TI website, it runs perfectly at 915MHz and a 38kB Baudrate but when I try to change the Baudrate (preferably to 500kB) the CC430 wont send or receive the signal. Is there something I need to change besides the registers to make this work properly? I have had the 500kB baud rate working on the Fixed_LT_FIFO so i know the register settings work and its not a board issue. I've noticed in the pktRxHandler that it will not detect the CC430_STATE_RX meaning there isn't anything being written to the FIFO. But the receiver will recognize that there is an incoming signal (i.e. it starts running the received signal code but wont recognize that there is anything in the FIFO).
The register settings used are as follows
RF_SETTINGS rfSettings = {
0x0c, // FSCTRL1 Frequency synthesizer control.
0x00, // FSCTRL0 Frequency synthesizer control.
0x23, // FREQ2 Frequency control word, high byte.
0x31, // FREQ1 Frequency control word, middle byte.
0x3B, // FREQ0 Frequency control word, low byte.
0x0E, // MDMCFG4 Modem configuration.
0x3B, // MDMCFG3 Modem configuration.
0x03, // MDMCFG2 Modem configuration.
0x22, // MDMCFG1 Modem configuration.
0xF8, // MDMCFG0 Modem configuration.
0x00, // CHANNR Channel number.
0x62, // DEVIATN Modem deviation setting (when FSK modulation is enabled).
0xB6, // // FREND1 Front end RX configuration.
0x10, // FREND0 Front end TX configuration.
0x10, // MCSM0 Main Radio Control State Machine configuration.
0x1D, // FOCCFG Frequency Offset Compensation Configuration.
0x1C, // BSCFG Bit synchronization Configuration.
0xC7, // AGCCTRL2 AGC control.
0x00, // AGCCTRL1 AGC control.
0xB0, // AGCCTRL0 AGC control.
0xEA, // FSCAL3 Frequency synthesizer calibration.
0x2A, // FSCAL2 Frequency synthesizer calibration.
0x00, // FSCAL1 Frequency synthesizer calibration.
0x1F, // FSCAL0 Frequency synthesizer calibration.
0x59, // FSTEST Frequency synthesizer calibration.
0x88, // TEST2 Various test settings.
0x31, // TEST1 Various test settings.
0x09, // TEST0 Various test settings.
0x47, // FIFOTHR RXFIFO and TXFIFO thresholds.
0x29, // IOCFG2 GDO2 output pin configuration.
0x06, // IOCFG0 GDO0 output pin configuration. Refer to SmartRF® Studio User Manual for detailed pseudo register explanation.
0x04, // PKTCTRL1 Packet automation control.
0x05, // PKTCTRL0 Packet automation control. (5 does not work)
0x00, // ADDR Device address.
0x64, // PKTLEN Packet length.
Update: I think I've determined that the issue is due to the Timer interrupt in the ReceievePacket and TransmitPacket Sections. Under the standard Baudrate of 38k it interrupts every couple of ms to see if the remaining bytes in FIFO is under 64 or not. If I speedup the Baudrate and lower the RX_TIMER_PERIOD and TX_TIMER_PERIOD i can start increasing the baudrate a little at a time with successful results. Unfortunately as the RX_TIMER_PERIOD value started at 80 and needed to be lowered 5-10 for a 5kB increase this is not a great solution. I can set the timer's clock to the SM CLK at 1 MHz instead of the ACLK at 32kHz allowing me to get the distance on RX_TIMER_PERIOD that is needed (I think). The issue kept occurring but I was able to get a little bit faster (160kB) so I thought I would increase the clock rate again to 20MHz to try that but it didn't really get the results that I expected. The baud rate did increase but only by 8 or so kB giving me a final of 168. When transmitting above this baudrate I cannot even get the End of packet TX interrupt to signal. Anything below 168 the End of Packet TX interrupt will raise telling me that there is at least something being transmitted but if I raise the baud rate above 160 the interrupt flag never sets.
Is there another way to transmit packets of size 100 besides using the timers (i.e. interrupts) because i think that this entire issue has to do with the interrupts not firing fast enough. It seems like even when trying to transmit that the interrupts are not occurring leading me to think they cant run fast enough for anything over 168kB.
Thanks,
Brian