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.

TX_UNDERFLOW state

Other Parts Discussed in Thread: CC2510

I am logging the value in MARCSTATE after sending an STX strobe and arming a DMA channel.  It doesn't seem to make any difference in what order I do those two things.  MARCSTATE progresses as expected from the IDLE state (01) through the states 07 - 09 - 0A - 0B to the TX state (13H). The DMA operation completes at the same time as the transition to the TX state.  About 230microsec later it enters the TX_UNDERFLOW state.  I've tried fixed and variable lengths for the transfer count.  The DMA channel is set to go to RX on end of transmission but I've also tried telling it to go to IDLE.  Whatever we do it seems to insist on going to the TX_UNDERFLOW state (16H).

Is there any other possible cause of a TX_UNDERFLOW state, or can this only mean that we have some setting wrong in the DMA configuration or one or more of the radio registers?

Thanks,

Ken Wood

  • Hi Ken,

    Have you looked at the code examples for CC2510/CC1110 called something like "CC1110/CC2510 Example Software Supported on IAR Embedded Workbench" (www.ti.com/lit/zip/swrc085)? This is the Packet Error Rate test and shows how to sue DMA for packet TX and RX.

    In your case, it seems there might be something wrong with the DMA config or the packet you are sending. You end up in the TX_UNDERFLOW state because the radio packet engine wants to transmit more data over the air than you (the DMA channel) have sent to it. That is, if you are using fixed packet length, the radio packet engine expects to receive (from the DMA channel) exactly the number of bytes specified in the PKTLEN register. If you are using variable length packets, the packet engine expects to get exactly the number of bytes (+ the length byte) specified by the first byte transferred by the DMA.

  • Hi,

    Thanks for the reply.  I'll have a look at the sample code to see if it sheds any light on the problem.

    Initially we were using variable length and, suspecting there could be some misunderstanding of what 'n' should be, we then tried fixed length.  One thing I've tried recently is to change the DMA configuration so that the destination address is an area of memory, and also set it to autoincrement the destination address.  When I do this the data is correctly copied to the selected area of RAM, which seems to me to confirm both that the packet length is right and that the DMA transfer is being triggered.

    I note you say there must be "exactly the right number of bytes".  Recently I have been trying deliverately sending too many - is it as important not to send too many as not to send too few?

    Can I just make sure I understand how we initiate the transfer.  As well as sending the STX strobe, all we have to do (having set up the configuration and loaded its address into the DMA configuration registers) is to arm the DMA channel - right?  We don't have to take any notice of the RFTXRXIF bit ?

    Finally, is there any significance in the fixed delay of about 230microsec after entry to TX state before the transition to TX_UNDERFLOW?  The clock is 26MHz and PKTLEN is 8, with an 8 byte preamble & 4 byte SYNC (data rate 500kbit/s).  230 microsec seems to be just about the time we should be starting to send the payload.

  • Take a look at the attached code. It shows both how to transmit using variable and fixed length packets.

    You should avoid writng more data than necessary to the RFD register. If you write more (and the radio is not in TX state), the data will simply be ignored.

    As you can see in the code, you do not need to worry about the RFTXRXIF bit when using DMA.

  • Thanks - the problem was that I was using burst mode rather than single.

    Now that we no longer see the TX_UNDERFLOW state, another concern arises.  We have MCSM1 set to go to RX when TX is finished.  MARCSTATE goes to state 10H (TXRX_SETTLING) which seems reasonable, but then it goes to state 17H, which is not listed in the datasheet, before entering the RX state 0DH.  So what is state 17H?

  • This is just an internal state, where the radio will wait for the synth to settle.