• State Resolved
  • Locked Locked
  • Replies 4 replies
  • Subscribers 57 subscribers
  • Views 1453 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

Questions about RF and GPIO output timing

Ed Bokhour
Prodigy 40 points
Other Parts Discussed in Thread: Z-STACK, CC2530

Hi, all!  I'm new at both ZigBee and programming for the CC2530.  I apologize if my questions have been answered elsewhere, but I've looked and looked and not found them.  I'm using Z-Stack 2.3.1 with the CC2530ZDK, which includes the RF05EB.  I've been modfiying the Sensor Demo application on both the Sensor and Collector sides, using IAR EW.

I'd like to set a GPIO bit high just before I send out a series of 10 packets on the radio, and have it go low again once the packets are transmitted, but this seems much harder to do than I expected.  It's easy to set the GPIO bit (I highjacked the LED3 signal) in response to an incoming command message.  But the RF output responses do not come when I think they should.  In fact, they almost never seem to come with the GPIO bit set high, as if the CPU won't issue the transmit commands while the LED3 signal is high.  Typically I see one output RF pulse (detected in the time domain using a wideband RF log-detector) 5 msec before the GPIO bit goes high, which I'm guessing is an ACK response.  There are also RF pulses roughly every 80-100 msec after the bit goes low. which I think may be my response packets.

I originally tried doing this from within the zb_HandleOsalEvent function (in the DemoCollector.c app), but I thought that the OSAL event handler may not be as deterministic in terms of signal timing.  So, now I've got it in the zb_ReceiveDataIndication function, but the move did not seem to change things in any significant way.

It looks to me now like the radio transmits when it's ready, and not in any way that's synchronous with the CPU, or at least with the application layer.  Is that correct?  Is this because the zb_SendDataRequest puts the data in a queue in the CSP?  If so, I'm wondering if there's a way to give commands more directly to the radio.  In particular, the maxTxFrameRetransmit() function looks like it would be perfect, but I don't think you can call that function from the application - at least I have not been able to do so successfully.  I also tried reading the TX_ACTIVE register, but I think it's changing too fast for the application to catch it.

Is there documentation I can look though which describes how the CC2530 radio commands and application timing are related?  The CC2530 User Guide does not seem to cover this, and I've found nothing in any of the Z-Stack API documents.  The routine I'm playing with is given below.

 

void zb_ReceiveDataIndication( uint16 source, uint16 command, uint16 len, uint8 *pData  )

{   

  if ( command == SENSOR_REPORT_CMD_ID )

  {

    HalLedSet ( HAL_LED_2, HAL_LED_MODE_FLASH );     // Flash LED 2 once to indicate data reception

    osal_stop_timerEx( sapi_TaskID, MY_REPORT_EVT );   //Stop default timer

    osal_clear_event( sapi_TaskID, MY_REPORT_EVT );    //Clear any report events outstanding

    zb_SendDataRequest (gtwData.source, MEASURE_CMD_ID,1,10, 0,0,0);

    P1_4 = 1;    // Set signal bit high (on RF05 board, EM_CS/EM_LED3_SOC signal on Port1.4 is asserted).

       // Send out 10 duplicate commands. 

       for (uint8 n=0; n<10; n++) 

       {

         zb_SendDataRequest (gtwData.source, MEASURE_CMD_ID,1,10, 0,0,0);

       }

    P1_4 = 0;      // Set signal bit high (on RF05 board, EM_CS/EM_LED3_SOC signal on Port1.4 is asserted).

  }

}

 

 

Thanks in advance for any pointers, insights, or suggestions!

ebok

  • 0
    TI__Mastermind 19350 points

    You will probably get the results that you want by toggling your GPIO in zmac_cb.c on the MAC_MCPS_DATA_IND and MAC_MCPS_DATA_CNF events. Be very careful about the code you add because this is a live callback from the MAC and you can easily screw up the MAC timing. Also, the data consists of a sophisticated system of pointers that may be freed or not - don't touch no buttons.

     

  • 0 in reply to Dirty Harry
    Prodigy 40 points

    Thanks, Harry!  That got me very close, though I could not find a place to turn off the GPIO which did not end up following an ACK transmission much later on.  This makes sense, since I think the callback should be waiting for a transmission acknowledgement.  I really wanted to turn off the GPIO when the output RF transmission had completed, and I got a lot closer by putting the GPIO toggles into mac_csp_tx.c.  Specifically, P1_4 = 1 went into the macCspTxPrepCsmaUnslotted() routine, and P1_0 went into macCspTxStopIsr().  These are the *only* additions to these files, so I'm hoping the MAC timing will be OK.  Thanks again for the help.

  • 0 in reply to Ed Bokhour
    Intellectual 745 points

    I am new to the CC2530 and I think I might be having a similar problem. I'm using hardware with the CC2530 and the ZStack 2.3.1.  In the hardware there is a switch that controls the Receive/Transmit path.   The switch is controlled through one bit on a 8 bit shift register.  So for example, before I transmit I need to shift 8 bits out in order to turn the Transmit path and then to Receive I need to shift out another 8 bits to enable the Receive path.  In mac_tx.c there are the functions txGo() and txCsmaGo().  These functions in return call void macCspTxGoSlotted(void) and void macCspTxGoCsma(void).

    In macCspTxGoCsma() below, the receiver is turned on before the CSP application runs.  This is a similar call to  MAC_RX_WAS_FORCED_ON() in macCspTxGoSlotted().

    I'm not sure where I can control the Rx/Tx path?  I'm also wondering if writing out to this shift register is going to throw of the ZStack timing?

    Can anyone shed any light on this?

    Thanks!

     

    MAC_INTERNAL_API void macCspTxGoCsma(void)
    {
      /*
       *  Set CSPX with the countdown time of the CSMA delay. 
       */
      CSPX = macTxCsmaBackoffDelay;

      /*
       *  Set WEVENT to trigger at the current value of the timer.  This allows
       *  unslotted CSMA to transmit just a little bit sooner.
       */
      CSP_WEVENT_SET_TRIGGER_NOW();

      /*
       *  Enable interrupt that fires when CSP program stops.
       *  Also enable interrupt that fires when INT instruction
       *  is executed.
       */
      MAC_MCU_CSP_STOP_ENABLE_INTERRUPT();
      MAC_MCU_CSP_INT_ENABLE_INTERRUPT();

      /*
       *  Turn on the receiver if it is not already on.  Receiver must be 'on' for at
       *  least one backoff before performing clear channel assessment (CCA).
       */
      macRxOn();

      /* start the CSP program */
      CSP_START_PROGRAM();
    }

  • 0 in reply to Dirty Harry
    Prodigy 55 points

    hello，sir

    The RTS output is driven low when the receive register is empty and reception is enabled, this is in CC2530 datasheet.  what time is  RTS output is driven high in flow application? when the receive buffer is full , the RTS is right now auto set to high ?

     thank you !