MC13213 - No Radio output

[rajendrams]

I have new board which has RF circuit according to MC13213 reference design. I do not receive the data transmitted from this board to the receiving side SRB. The T/R switch is powered correctly.

The data is transmitted with:
MCPSDataRequest(&gsTxPacket); /* Transmit the packet */

The same software runs fine on the reference SRB boards.

Can your provide any clues to solve this issue.


Best Regards,

rajendra.

[RichTestardi]

Can you enable the Out of Idle indicator on pin GPIO1?

When gpio_alt_en, Register 9, Bit 7 = 1, GPIO1 functions as an “Out of Idle” indicator.

This will verify if the MC13213 thinks it transmitted a packet or not.

-- Rich

[rajendrams]

The GPIO1 is configured High. The CT_BIAS signal (T/R switch) show a pulse waveform with 50microsec High and 5ms period. which probably means there is data transmission taking place??

do you mean that GPIO1 should be configured to be ON/OFF as per the Transmit periods like the T/R switch waveform?

Thanks for Replying.

Best Regards,

Rajendra.

[RichTestardi]

I've found the GPIO1 to be very useful to tell me when the transceiver leaves the idle state -- generally meaning it is transmitting a packet or is waiting to receive a packet.

I configure it as follows (pseudocode):

    reg0x09 = (reg0x09 & ~0x00a0) | 0x00a0    // set gpio_alt_en

    reg0x0b = (reg0x0b & ~0x0081) | 0x0080    // configure GPIO1 for output

Thereby performing two read-modify-writes of registers 0x09 (Control_C) and 0x0b (GPIO_Dir).  This assumes your GPIO1 pin is otherwise unused in your circuit.

Then, with a scope on GPIO1, assuming you don't accidentally have the transceiver waiting to receive, you can see exactly when each packet is transmit.

(I also found my driver was accidentally returning to idle this way due to bug #2 in the errata, because the GPIO1 deasserted after 67 seconds with no interrupt!)

[RichTestardi]

I probably should have mentioned...

Once you configure GPIO1 using those two lines, then the transceiver itself takes control of the GPIO1 pin and asserts it automatically when the transceiver leaves the idle state, and deasserts it again when the transceiver returns to the idle state...

In other words, you no longer have to (or probably even can!) manipulate the GPIO1 pin by hand -- it happens automatically behind the scenes, as a side effect of normal transceiver usage by your program.

See MC1321xRM.pdf section 3.4.5 and 3.7.

[rajendrams]

Thank you Rich. I shall test this and reply.

Best Regards,
Rajendra.

[rajendrams]

I was not able to find the documentation to change the register 9/CONTROL_C. Can you help to give the exact code snippet to

Secondly,the GPIO1 is powers the T/R switch. do I need to make any changes in hardware to configure the GPIO1 as gpio_alt_en.


Best Regards,

Rajendra.

[RichTestardi]

> I was not able to find the documentation to change the register 9/CONTROL_C.

> Can you help to give the exact code snippet to

It will depend on the exact code you are using...  If you are using SMAC (I am not), it

would look like:

{

  UINT16 reg09;

  UINT16 reg0b;

  reg09 = SPIDrvRead(0x09);

  SPIDrvWrite(0x09, (reg09 & ~0x00a0) | 0x00a0);  // set gpio_alt_en

  reg0b = SPIDrvRead(0x0b);

  SPIDrvWrite(0x0b, (reg0b & ~0x0081) | 0x0080);  // configure GPIO1 for output

}

> Secondly,the GPIO1 is powers the T/R switch.

> do I need to make any changes in hardware to configure the GPIO1 as gpio_alt_en.

Oh, bummer, then you can't take advantage of the GPIO1 Out of Idle indicator.

I've found it useful to try and determine what the transceiver is doing -- if you have other GPIO pins you can move the T/R switch to, you might want to try and leave GPIO1 and GPIO2 (CRC Valid Indicator) for debugging...

[rajendrams]

I use SMAC for communication.

I followed the design from SRB as is where GPIO1 controls VDD of μPG2012TK-E2. may be VDD can be tied to 2.8V instead and then use the GPIO1 for monitoring?
Will toggling the GPIO1 affect the performance of μPG2012TK-E2? at present i only need to transmit the data and there is no need to receive any information. in the later phase of project i shall need both transmit and receive.


Secondly, I believed that CT_BIAS was a good enough indicator that MC13213 is in transmit mode. because it does shows High on transmit and low otherwise.

The difference in the observation between the same code working on SRB and on my hardware is that SRB readings at CT_BIAS show a high pulse width of about 500microseconds and on my hardware it is about 150microsec.

Is there any other different setting of the processor that may hold it from powering up the RF section? I tried output power setting to normal and maximum but there is no RF output.


Thanks.

Rajendra.

[RichTestardi]

> Will toggling the GPIO1 affect the performance of μPG2012TK-E2?

Yikes, I would have no idea, and there does not seem to be any timing data for either the Out of Idle indicator or the switch VDD response.  It sounds like you just have to give up the Out of Idle indicator.

> Secondly, I believed that CT_BIAS was a good enough indicator..

Yes, I agree for transmit.  I see my CT_BIAS assert for ~800us for a packet with 12 byte payload, but I'm in Single Port Mode so the timing might not compare exactly to yours.

If CT_BIAS is asserted for warmup, payload, and warmdown, which it seems to be, you should see it for:

144us, for warmup

(8+n)*32us, for n payload bytes

10us, for warmdown

So for 12 payload bytes (in my case) that is 144+(8+12)*32+10 = 794us.

If you are seeing 500us, that would mean you're sending 2-3 payload bytes?

> Is there any other different setting of the processor that may hold it from powering up the RF section?

It seems the transceiver is running from what you say, so it might just be an electrical problem in the transmit path?

-- Rich

[RichTestardi]

Oh!  And if on the board that is not transmitting, you see CT_BIAS for 150us, then it looks like the total number of bytes transmit is 0!!!  That means, not even the normal 4 bytes of preamble, 1 byte of SFD, 1 byte of FLI, and 2 bytes of FCS.  It looks like you just have a warmup/warmdown sequence!  Weird!  Can you check your IRQ_Status and make sure you're not experiencing one of the weird errors like pll_lock_irq, ram_addr_err, arb_busy_err?