• State
  • Locked Locked
  • Replies 4 replies
  • Subscribers 80 subscribers
  • Views 1173 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Chronos Firmware - Strobe function in rf1a.c possibly incorrect?

darkwzrd
Expert 1385 points
Other Parts Discussed in Thread: CC1101, SIMPLICITI

Hi all,

I decided that since I have this week off from work, I would spend some time looking into this Chronos watch that I've had sitting on my desk for 6 months. After a cursory look at the RF1A module in the Users Guide, I decided "to hell with it" and to just jump right into the firmware (http://www.ti.com/lit/zip/slac341) for a hands on look.

After stepping through the code a bit, I found the definition for the strobe function in rf1a.c. Line 45 has the following:

  if((strobe == 0xBD) || ((strobe > RF_SRES) && (strobe < RF_SNOP)))

Unless I've got my head screwed on backwards, it appears that the code is rejecting RF_SRES and RF_SNOP as valid strobes since the conditions are not inclusive (>= and <=).

When stepping through the init code, radio_reset was called from radio.c.

Stepping through the Strobe(RF_SRES) line just exits and does not actually send the strobe.

Can someone confirm that is was intentional? Seems rather suspicious to me.

Thanks

darkwzrd

 

  • 0
    Guru 227245 points

    I don't know the code and therefore the values of RF_SRES and RF_SNOP or any other possible values or flags in strobe.
    But there is another sufficient condition in this line: srobe == 0xBD. So maybe RF_SRES or RF_SNOP alone are not legal, but a combination that includes one of them or both?

  • 0 in reply to Jens-Michael Gross
    Expert 1385 points

    Excerpt from the cc430x613x.h header file:

    /* Radio Core Instructions */

    /* command strobes               */

    #define RF_SRES             0x30      /*  SRES    - Reset chip. */

    #define RF_SFSTXON          0x31      /*  SFSTXON - Enable and calibrate frequency synthesizer. */

    #define RF_SXOFF            0x32      /*  SXOFF   - Turn off crystal oscillator. */

    #define RF_SCAL             0x33      /*  SCAL    - Calibrate frequency synthesizer and turn it off. */

    #define RF_SRX              0x34      /*  SRX     - Enable RX. Perform calibration if enabled. */

    #define RF_STX              0x35      /*  STX     - Enable TX. If in RX state, only enable TX if CCA passes. */

    #define RF_SIDLE            0x36      /*  SIDLE   - Exit RX / TX, turn off frequency synthesizer. */

    //#define RF_SRSVD            0x37      /*  SRVSD   - Reserved.  Do not use. */

    #define RF_SWOR             0x38      /*  SWOR    - Start automatic RX polling sequence (Wake-on-Radio) */

    #define RF_SPWD             0x39      /*  SPWD    - Enter power down mode when CSn goes high. */

    #define RF_SFRX             0x3A      /*  SFRX    - Flush the RX FIFO buffer. */

    #define RF_SFTX             0x3B      /*  SFTX    - Flush the TX FIFO buffer. */

    #define RF_SWORRST          0x3C      /*  SWORRST - Reset real time clock. */

    #define RF_SNOP             0x3D      /*  SNOP    - No operation. Returns status byte. */

    0xBD is a RF_SNOP with the most significant bit set. The CC1101 radio within the CC430 always returns a status byte when an instruction is sent. Encoded within the byte is information about the status of either the RXFIFO or the TXFIFO, depending on whether the MSBit is a 1 or a 0. Having a 1 means that the RXFIFO status is returned, and 0 means TXFIFIO status is returned.
    Strobe(RF_SRES) is supposed to reset the CC1101, and is called during initialization. I find the logic very suspicious. I think I'm going to need to fetch my can of RAID and get to work! :)
    I'm sure its not the only bug in there. I've already found out that the code sets VCore and inits the frequency twice, with no code in between to justify different values for frequency (one was done at __low_level_init from the SimpliciTI BSP and the other at the beginning of main). It also messed up the delay required in one of those instances.

  • 0 in reply to darkwzrd
    Guru 227245 points

    So an incoming SNOP from the RXFIFO is accepted, but not from the TXFIFO but an SRES is ignore in any case. THis might make sense if the code inside teh IF block won't handle the SRES. Maybe it is/has been already handled somewhere else.

    darkwzrd said:
    I find the logic very suspicious

    The main problem is that there is (as usual) no comment about what this code is intended to do. Maybe the logic is exactly what it has to be, yet without any explanation, I agree, it's suspicious.

    darkwzrd said:
    I'm sure its not the only bug in there

    There's always at least 1 bug more than you discovered :)

    darkwzrd said:
    I've already found out that the code sets VCore and inits the frequency twice, with no code in between to justify different values for frequency (one was done at __low_level_init from the SimpliciTI BSP and the other at the beginning of main). It also messed up the delay required in one of those instances.

    I guess, the programmer of the main didn't know that the programmer of the SimpliciTI code already messed with the VCore - due to lack of documentation. :)

  • 0 in reply to Jens-Michael Gross
    Prodigy 240 points

    I have been using portions of the Chonos firmware as a basis for a wireless firmware upgrade on my own CC430 based hardware. To add to this thread the code in question does not actually effect the normal operation of the main "Sports Watch" firmware as SimpliciTI has it's own version of the Strobe function:

    mrfiRadioInterfaceCmdStrobe  which contains the assertion:

    MRFI_RIF_ASSERT( (addr == 0xBD) || (addr >= RF_SRES) && (addr <= RF_SNOP));

    I have found that where this DOES have an effect is in the "Wireless Update" project (the Bootstrap for the RFBSL function).  Since this does not contain SimpliciTI it replies on functions in the basic rf1a file.  The version of the rf1a that ships with the Chronos package is the only one I can find that has the "or equal to" comparisions removed.  The file appears on many other CC430 sample projects with an if/assertion as above.

    The RFBSL function does issue RF_SRES commands but is able to still function (by dumb luck) even though they are never actually sent due to this bug.  However if you correct the bug the RFBSL function no longer functions.  In particular the #ifndef below has to be removed since when the radio is *really* reset the registers must be setup again.  This refers to the RAM variation of the project which runs after the BSL has loaded it.

     

    // Prepare radio for RF communication

        radio_reset();

     

    #ifndef RAM_BASED_RFBSL 

        // It only needs to be configured when the Flash Based RFBSL is running since when the RAM RFBSL

        // runs, the radio registers are already configured - NOT TRUE IF RESET IS ACTUALLY PERFORMED ABOVE

        config_radio_wbsl();

    #endif

     

    After many hours on this building a version of the RFBSL for my own hardware I was wondering - was this change to the Strobe function in rf1a done intentionally in the Chronos release and if so why?

**Attention** This is a public forum