• State
  • Locked Locked
  • Replies 3 replies
  • Subscribers 53 subscribers
  • Views 1300 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.

CC1200 Problems with streaming packet data using RXOFF_MODE and TXOFF_MODE to optimize TX/RX transitions.

Christopher Ingraham
Intellectual 1000 points
Other Parts Discussed in Thread: CC1200

I have configured two CC1200 radios so that they will ping-pong between TX and RX modes.  One radio sends a packet to the other and then transitions to RX mode waiting for an "Ack" packet.  The other radio received that packet of data and automatically transitions to TX mode to send it's ack.  I have set up the system so that I've pre-loaded packets in the TX Fifos so that when the RX to TX transition occurs, the radio should immediately start sending what's in the TX Fifo.  I am successfully able to run in this mode for a short period of time where I am able to perform anywhere from 50 to 800 successful transactions.  However, eventually, things hang with both radios "stuck" in RX mode.


I have configured the RFEND_CFG1 and RFEND_CFG0 register values to be 0x2F and 0x30 respectively in both CC1200 devices.  With this scheme, I'm able to send one of my large packets every 1.44ms until the system locks up with both devices stuck in RX mode.

Is there some error status that I could possibly check to recover from this lock-up?  Is there some way for me to avoid the lock-up?  I realize that the system is going to need to be tolerant of lost or garbled packets.  And I will need to be able to restart the packet transfers.  However, I don't think that's the problem I'm seeing at the moment.  Before I started trying to add this ack capability to the system, I was able to transmit over 9000 packets at speeds of about 1.1ms per packet without a single dropped packet or checksum issue.  So I believe my test environment is fairly "RF quiet" and I shouldn't be dropping packets due to noise in my lab.

I'm at a bit of a loss as to what I can check at this point.  Any suggestions would be greatly appreciated.


Thanks,

Chris.

  • 0
    TI__Guru* 86071 points

    Hi

    If you are using TXOFF_MODE = RX and RXOFF_MODE = TX and try to send packets back and forth this will fail as soon as one packet is missed. See figure below:

     

    When a packet is not received by unit A it will be stuck in RX, Unit B, sending the packet that was lost, will enter RX and be stuck since no packet is sent from A (which also is stuck).

    The only way to get this to work is to have an RX timeout on both units timing out at the same time as a packet has been received, and which takes the radio into TX again.

     Siri

  • 0 in reply to Siri
    Intellectual 1000 points
    Hello Siri,

    Thank you for getting back to me so quickly. I figured that this would be what the problem was. I do have a couple of follow-up questions though.

    I'm trying to maximize the data throughput in the system. If I use a timeout to detect the problem, what is the fastest way to get the transmissions started again. In all instances where things have locked up, I have seen that my TX Fifo is already loaded with the next message. Can I simply issue the STX_CMD to kick things off again or do I have to go back to IDLE first?

    Also, as I mentioned in my original post, before I added the TX-RX ping-pong functionality, I had one radio streaming data to the other radio (one always in TX mode, one always in RX mode) and I never dropped a packet or had a checksum error. What is it about the switching between TX and RX modes on the radio that would be introducing this failure? It could be coincidence, but it seems odd to me that the system works so reliably in one direction but as soon as I try bi-directional transfers, things fall apart quickly.

    Thanks again for your quick response!

    Best regards,
    Chris.
  • 0 in reply to Christopher Ingraham
    TI__Guru* 86071 points

    Hi Chris

    If you are “stuck” in RX, your TX packet has been sent. The FIFO is empty, meaning that the FIFO pointers are equal. If you want to transmit the same packet over again, you do not have to write it to the FIFO over again. You simply have to move your FIFO pointers. How this can be done is described in section 3.2.3 (Direct FIFO Access) in the user guide. It is fully possible to strobe STX again directly from RX without going through the IDLE state.

    I do not think you lose packets due to CRC errors or unreliable link, but rather due to timing issues. If you have a logic analyzer you should connect it to both nodes and monitor the two MARC_2PIN_STATUS signals when running your code. In addition you could monitor PKT_SYNC_RXTX. This would probably give you an explanation as to where/why things fail after a while.

    BR

    Siri