• State Resolved
  • Locked Locked
  • Replies 6 replies
  • Answers 2 answers
  • Subscribers 56 subscribers
  • Views 1383 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.

Using DMA to read/write packet data RF1A on cc430

pmaheral
Prodigy 60 points


I'm am porting an application from a cc1110 to a cc430 based system.  In this app, we use large packets (64-255 bytes), and make extensive use of DMA to transfer packet data to/from the radio.  I have been unable to find any example code, or information on how to use DMA with the RF1A peripheral on the cc430.

Is the following pseudo code correct?

To receive a 200 byte packet from the radio:

  1. Set DMA destination to the packet buffer with address increment
  2. Set DMA source to RF1ADOUT1B (autoread 1 byte register) with no address increment
  3. Set DMA size to 200
  4. Set DMA trigger to RFRXIFG
  5. Flush Rx FIFO
  6. Write SRX instruction to RF1AINSTRB
  7. Enable DMA
  8. Write RXFIFORD to RF1AINSTR1B
  9. Wait for DMA to complete
  10. Process packet

What happens on the final DMA read from the auto-read register?  Will the auto-read cause an underflow?  The non-DMA example code for reading N bytes of data from the Rx FIFO reads RF1ADOUT1B N-1 times (i.e. 199 in this example), followed by a single read from RF1ADOUTB.  When using DMA, should the DMA transfer size be set to N-1 (199 here), and use an ISR to handle reading the the final byte?

Another concern that I have with DMA is how it might be affected by Rx FIFO pointer bug described in section 22.3.3.8 Data FIFO of the cc430 User Guide (SLAU259b.pdf).  If the DMA transfer is keeping up the the radio (as expected), it will be emptying the FIFO on every read.  The recommeneded method is to not empty the FIFO until the packet has been completely received.  Do we need to worry about this when using DMA?

 

 

  • 0
    TI__Genius 17802 points

    pmaheral,

    RFRXIFG & RFTXIFG triggers for DMA are part of an RF1A feature planned for possible future implementation of the CC430 devices. However, it is not available today on the CC430 and the mentioning in the datasheet unfortunately wasn't taken out after the initial planning. Therefore those hooks are not available to notify the status of the RF FIFO buffer (empty/not empty) or to control the DMA transfer. We will correct this in the datasheet shortly.

    You can still try to use DMA with the RF1AINSTR1B as you described, but with special handling in SW to keep track of how many bytes being transferred.

    1. If packet size is < FIFO (unfortunately this is not your case), best method would be triggering a manual single block transfer once the last RX byte is received.

    2. If packet size > FIFO, set up a wake up interval (timer A?) to check the number of bytes available in the buffer, trigger a manual single block transfer, and go back to sleep.

    You are also correct on the handling of the last byte in the FIFO. The size of the DMA transfer should be # of bytes in FIFO - 1; the last byte should be read manually. The RX FIFO pointer issue is no longer a concern with a block transfer, however.

    Also please take into consideration of the timing synchronization between each DMA transfer (~2MCLKs) and the time it takes for the data out register of the RF1A Interface (RF1ADOUTx) to become ready again.

     

    Regards,

    Dung

     

  • 0 in reply to Dung Dang
    Prodigy 60 points

    Hi Dung,

    Thanks for the info.  In our application, we receive many packets that are smaller than the FIFO, so, for those, we can use method 1, however, that will increases the latency more than the previous design.  Unfortunately, the majority of our Tx packets are larger than the FIFO, so we will have to resort to method 2 for those.

    Can you clarify the last two points you made?  First, what do you mean by: "The RX FIFO pointer issue is no longer a concern with a block transfer".

    Second, how can we "take into consideration of the timing synchronization between each DMA transfer (~2MCLKs) and the time it takes for the data out register of the RF1A Interface (RF1ADOUTx) to become ready again."  From slau259b:

    In correctly written software(1) the delay will be only triggered when the synchronization between the CPU and the RF clock domain requires more than one CPU clock cycle.  The delay of up to 16 CPU clock cycles accounts for the worst case conditions and ensures that the synchronization can be completed under all conditions before the read or write access is completed.

    The CPU clock and RF clock are not synchronous (MCLK @ 20MHz and RF @ 26MHz), so a delay will mostly likely be introduced.  How do we ensure that the DMA transfer reads valid data from the FIFO?


    Patrick

  • 0 in reply to pmaheral
    TI__Genius 17802 points

    Patrick,

    1. The UG indicates that:

     

    If a received data byte is written to the RX FIFO at the exact same time as the last byte in the RX FIFO is read, the RX FIFO pointer is not properly updated and the last read byte is duplicated. To avoid this problem one should never empty the RX FIFO before the last byte of the packet is received.

    Specify each block transfer of size = # of bytes in FIFO - 1. Once the number of the remaining bytes is less than FIFO size, you can manage in SW to wait for the END_of_RX_Packet interrupt before triggering the final block transfer. This ensures never emptying the buffer.

    Sorry, by no concern I meant tiny software workaround :). 

    2. The radio interface supports a few access modes, particularly this delay mode where it can cause the CPU to stall (up to 16cycles) to "catch up". UG, section 22.2.6 provides some guidance on this:

    Agreeably, this is not a very elegant method, but at least it provides a solution to using DMA with RF1A.

    Regards,

    Dung

  • 0 in reply to Dung Dang
    Prodigy 60 points

    Dung,

    Can you confirm that DMA accesses can be stalled in the same manner as the CPU access to the interface registers?  If so, we can use a combination of an ISR and DMA to fill the Tx FIFO (with packets > 64bytes) without worrying about interface synchronization delays.  For small packet Rx, we will wait for the end of packet and use method 1 or 2 above to read out the data.

    Regards,

    Patrick

  • 0 in reply to pmaheral
    TI__Genius 17802 points

    Patrick,

    yes, the DMA accesses are stalled similarly to the CPU accesses. You should be able to use DMA & ISRs as described to handle longer-than-FIFO packets. 

    Regards,

    Dung

  • 0 in reply to Dung Dang
    Intellectual 680 points

    Has the DMA to RF Tx been implemented for the CC430? This was originally posted Aug 2010.

    If not, can someone post C example of the Tx larger than 64 bytes Tx? Also, C example of using DMA to Tx 64 bytes... if it is possible.