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.

The PKT_SYNC_RXTX signal of receiver is shorter than transmitter's in SimpliciTI with infinite packet length mode

Other Parts Discussed in Thread: SIMPLICITI, CC1200

Hi,

I has ported SimpliciTI 1.2.1-Beta to CC1200 TrxEB. I also integrated CC112x's Infinite Packet Length Mode to it. Following are the conditions I use:

1.2kbps RF data rate
System clock: 25MHz
SPI clock: 8.3MHz
FIFO_THR = 80
2-byte length field of Infinite Packet Length Mode
Application of SimpliciTI: main_AP_Async_Listen_autoack and mainEDs_autoack
Overhead of SimpliciTI protocol header including 2-byte length filed: 13 bytes

Now I have a problem: After Join and Link procedure, when I tried to let ED send 50, 100, 150, 200, 250, 280 bytes packets to AP separately, just the case of sending 250 bytes packet had something wrong. AP always received a incomplete frame. The total payload size of radio frame is 250 + 13 = 263. The first 245 bytes of 263 were correct. The else had the same value and were wrong. However the frame could be correctly received by a Sinffer which was only running a simple Infinite Packet Length Mode ported from CC112x.
(Updated: with advanced test, only transmitting 232 bytes ~ 279 bytes payload has this issue)

The following is the detail:
In AP/Rx side, when reading first 2-byte length field and 81 bytes data in every RxFifoAboveThresholdIsr iterations, the MARCSTATE was normal. Therefore the first 245 bytes were correct. However when the S/W tried to read the remainder data in the packetReceivedIsr ISR, it found MARCSTATE had RX_FIFO_ERROR. When the problem happened, I also observed that the PKT_SYNC_RXTX signal of Rx was shorter than Tx's by an oscilloscope. The Rx's PKT_SYNC_RXTX was deasserted almost at the same time with the end of last RxFifoAboveThresholdIsr ISR process. I am not sure if it is a chance or not.


The following is my conclusion:
1. I am almost sure the RF state wasn't switched by S/W at that time.
2. The Tx seems OK. The frame could be received by a Sniffer correctly.
3. The clock speed of MCU/System and SPI are first enough.

Do you guys have any comment for my problem? Thank!

Best regards,
Simon

  • - Does you port to CC1200 work as expected without implementing infinite packet mode?

    - Does infinite packet mode work on CC1200 without Simplicity? 

  • Yes. I ported just only SimpliciTI-IAR-1.2.1-Beta to CC1200 and it works well with Join, Link, and sending user data procedures.

    Yes, I also ported just only Infinite Packet Length Mode to CC1200 with 1.25Mbps RF data rate to evaluate the best throughput. It also works well.

    Next, I integrated Infinite Packet Length Mode to SimpliciTI-IAR-1.2.1-Beta. To support Infinite Packet Length Mode, I changed the original busy-wait Tx procedure of SimpliciTI to interrupt-based and let Tx and Rx procedures share the same three GPIOs. For example for Tx, without CCA mechanism, the GPIOs used for txFifoBelowThresholdISR and packetSentISR separately.

    I know the situation became more complex since Infinite Packet Length Mode was integrated. Tx and Rx state transition for full-duplex operation and error handling need to be considered.

    To simplify my question, by observing the Tx and Rx's PKT_SYNC_RXTX signals on the same oscilloscope screen, the Rx's was deasserted earlier than Tx's. Is there any reason/situation the Rx procedure of RF will be terminated abnormally?

    I have to note that again, all the radio frames can be correctly received by a CC1200 running a simple Infinite Packet Length Mode. So the Tx shall be OK.

    Thanks for your help.

    Best regards,

    Simon

  • BTW, will Rx FIFO error such as overflow or underflow cause the Rx's PKT_SYNC_RXTX signals to be deasserted early?

  • Yes, the signal will de-assert in the case of an over or underflow. To start with I would recommend looking into how many byte you really receive.

  • Dear all,

    Yes, the early-terminated reception was caused by FIFO error. After completing error handling of rx procedure, it works well now. With the max. payload size, 280 bytes, it achieves about 280 kbps.

    I am trying to increase the payload size but that seems to exhaust the memory? The program even can't be executed. I am asking for help in another thread.

    Anyway, thanks for your help.

    Best regards,

    Simon