Problem with MC13202

[prometheus]

Hi,
   I am trying to use a FPGA with MC13202 in stream mode. I used the recommended operation flow in reference manual and found that the chip works well in TX mode(I used a  CC2430 based sniffer to watch the packet transmitted). However, the chip does not received the packets correctly (Even if the RSSI is about -65 dbm ).
   The problem is, the receiver can receive a lot of wrong packets as well as the packets with correct CRC, and worst of all, after having received certain packets , the receiver cannot receive any more packets (the IRQ is not generated after the trigger). I have checked all the chip status in almost every step (e.g. the IRQ status after the IRQ is generated.) and the chip behaves exactly the same as the RM described.
    The RF board I am using is the reference design of 1320xRFC. Since the board can send the packet , I think that is not the problem of the board module or the SPI interface.

Does anyone meet the problem, or can anyone give some advice ?

Best regards.

Message Edited by prometheus on 2009-01-19 12:08 PM

[dwhite06]

Hi,

Unfortunetly, I am having even worst results than you when trying to use stream mode. Packet mode works fine, but I can't get stream mode to generate the appropriate IRQs for the receiver. The transmitter seems to behave the way the manual states, as far as the IRQs go. However, I have a few questions for you, since yours seems to work better than mine, and I need help and can't seem to get it from anywhere else.

1) When you write the packet length to the TX_PKT_CTL (Reg 03), are you adding the +2 for the FCS or are you just writing the number of data bytes you are transmitting. In other words, lets say you want to write two bytes of info (TX_PKT_RAM Reg 02 holds 16 bits of info at a time which is two bytes), I thought the way it works is you write 0x0004 hex to Register 03 (TX_PKT_CTL) to account for the two bytes of data plus the two bytes of FCS generated by the radio. Is this correct? Is this the way you did it?

2) After you transmit your data, does the IRQ Status come back as saying tx_done or do you have to toggle RXTXEN line first (or turn of the transmitter by writing to bit 12 of register 06 CONTROL_A)?

3) What frequency were you able to run at so that you didn't violate the 64us rule?

4) Does your receiver generate the proper IRQs? In other words, mine generates the IRQ for reset after power up and geneartes another one for when I first toggle the RXTXEN line after I am set up for stream mode. However, the next IRQ doesn't happen until I end the RX stream mode or toggle the RXTXEN line. The staus then gives me an RX_DONE. I don't get the IRQ for the packet length or the payload (data), eventhough I set all my masks to give me an IRQ when these things occur. I do not have a sniffer or any equipment to check that the transmission is occuring. I can only rely on the logic analyzer showing me that I wrote the correct info to the MC1320x using the SPI. I then rely on what the IRQ status tells me.

5) As far as your problem goes, it sounds like a timing issue. One of the things I noticed was that as you increase the frequency of the radio the frequency does in fact increase correctly but the duty cycle decreases from the 50% that it is at nominal, but only in certain spots. I am not sure what causes this to happen, but you may want to look at the clock over a long period of time with an logic analyzer to see what is going on. For instance, when I run at 4 MHz, the clock actaullly goes to 0% duty cycle (which means the clock is not there) for short periods of time when I look over a long period of time. Sometimes this occurs way out in time when the unit is sitting idle, and other times this occurs during reads and writes through the SPI. This was causing me many intermittent problems, and therefore I had to slow the clock down, which keeps me from being able to transmit more than two bytes of info, while not violating the 64 us requirement.

Any help you can provide would be appreciated. If I get mine to work, I will be glad to let you know what I did.

Best Regards

[prometheus]

Hi,

My problem was solved. For your questions:

1. You should write the actual PHY frame length into the TX_Pkt_Ctl

2. You'd better wait for the IRQ before toggle the RXTXEN line.

3. The SPI works at 3MHz

4. My problem described above  was solved by reading the ERRATA Documents(http://www.freescale.com/webapp/sps/site/prod_summary.jsp?code=MC13202&fpsp=1&tab=Documentation_Tab)  . It is a bug....

5. Sorry I cannot see what you mean.

My chip works fine in stream mode. Hope these can help you.

BR.

[dwhite06]

Hello BR,

Thanks for the information on the Errata. It appears that a new version of the errata came out on 4/2010. I will adjust my code to account for the "bugs."

I am still a little confussed by what you mean when you say PHY frame length. Assuming PHY means physical, to me the Physical Frame Length means the entire frame that gets transmitted, which would be 8 bytes plus whatever my data payload is.

When you say actual PHY frame length in to the TX_Pkt_Ctl, are you talking about the data payload and the FCS (in otherwords if I am sending two bytes of data, I would write 0x0004 in to TX_Pkt_Ctl to account for the two bytes of data and the two bytes of FCS)?

OR

When you say actual PHY frame length in to the TX_Pkt_Ctl, are you talking about the entire thing (Preamble, SFD, FLI, Payload Data, and FCS) which would be 8 bytes plus whatever my payload data is?

OR

When you say actual PHY frame length in to the TX_Pkt_Ctl, are you talking about just the Payload Data (not counting the Preamble, SFD, FLI, and FCS)?

I appreciate your help,

DW

[prometheus]

Sorry for my unclear reply.

PHY= IEEE 802.15.4 PHY Layer

"When you say actual PHY frame length in to the TX_Pkt_Ctl, are you talking about the data payload and the FCS (in otherwords if I am sending two bytes of data, I would write 0x0004 in to TX_Pkt_Ctl to account for the two bytes of data and the two bytes of FCS )?"

Correct. (Yes, you should write 0x0004)

Hope this can help you .

By the way: BR = Best Regards.   

[dwhite06]

I guess you figured out that I don't send text messages or use forums much, because I thought BR was your initials.

Thanks for the clarification. 0x0004 is what I have been trying to use, I just wanted to make sure I was interpretting the manual correctly. Unfortunetly, I am out of lab time for now. Hopefully I will get a chance to get back on this and try to get it to work. Right now, no matter what I do I can't seem to generate any interrupts for the receiver other than the reset after power-up and the rx_done_irq after deasserting rxtxen (going from a high to a low). I am not even sure if the transmitter is actually transmitting the data, even though all the irqs seem to be correct on the transmitter. I also still have portions of my clock that go away if I run at frequencies higher than 1 MHz. For frequencies 1 MHz and lower, the clock is there and the frequency is correct but the duty cycle (pulse width) is not 50%. As I decrease the frequency, the closer I get to the default clock, the closer I get to 50%.

Anyways, I appreciate all your help.