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-FIFO holding different packets

Other Parts Discussed in Thread: CC2550

Hello,

WHAT I AM DOING:
I have a question about the packet handling on CC2550.
The transmitter is basicly working fine.

I now wrote a firmware for an uC, to constantly refill the TX-Buffer with data.
I constantly send the same packet which includes the variable length byte.
First byte = 12 , then "Hello world\n" (ASCII-coded).
For data rates up to 300 kBaud (2-FSK) this seems to work fine.

THE PROBLEM:
If I try to increase the data rate I am getting the following problem:
The packets are valid for most part of the time. Yet, occasionally the
GDO-Pin, configured to display the start and end of a packet, shows a
changing packet length. The new packet length corresponds to one of the transmitted
ASCII-characters. It seems like a single byte is missing in the TX-FIFO Buffer.

My SPI-Interface is working at 6 MHz. The timing requirements of the datasheet are fullfilled.
I analysed the traffic with a Logic Analyser and the data being send is correct. The measurements
were made directly at the CC2550-Pins, so errors through capacites along the way can be excluded.

QUESTION:
My firmware is constantly sending new data to the TX-FIFO Buffer, when the treshold condition is met
(without exceeding its capacity). I am NOT waiting for a packet to be completly transmitted. In case of
the described test-packet, there can be data of different packets in the buffer. This case is not explicitly
discussed in the datasheet. Could this be the source of my problem ?


Thanks for any help


Kind regards






  • The system you describe should work.  The key statement for me is

    Michael T. said:
    For data rates up to 300 kBaud (2-FSK) this seems to work fine.

    Although your communications works properly, is there any possibility of FIFO underflow due to timing latency in response to signaling?  Your statement of slower data rates working suggests to me to look at overall timing not just interface timing.  Any possibility this could be an issue?

    Jim Noxon

  • The overall timings are within specs. I am not getting any FIFO underflows. However I now changed my design so that there is only data of one packet in the buffer. I than use the falling edge on GDO indicating the end of the packet to refill the buffer. It works perfectly now. However I still don´t understand what caused my troubles before that.

    However I have got another problem in receiving data now. I measured the transmit frequency and it does not correspond to the register settings. I am getting an offset of approximatly 60 kHz after calibration. Is this a phenomena you already encountered ? The oscillator at 26 MHz seems fine, but I will recheck it with a near-field-probe next week.