AT86RF212B Can't get PLL to lock? (No AVDD?)

Go To Last Post
21 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I am using the AT86RF212B in a newly designed board. The SPI interface seems to work properly, but I am having trouble getting the PLL status bit (SR_PLL_LOCK_CP) to return anything but 0 (unlocked) after issuing the trx_bit_write(SR_TRX_CMD, CMD_PLL_ON) command. Since the Software Programming Model doesn't give any detailed startup examples, I have implemented the following:

    /* AT86RF212::P_ON */
    AT_trx_pinset_slptr(false);
    AT_trx_pinset_reset(false);
    delay_us(400);
    AT_trx_pinset_reset(true);
    delay_us(1);
    AT_trx_pinset_reset(false);
    AT_trx_reg_write(RG_TRX_CTRL_0, CLKRST);
    AT_trx_reg_write(RG_TRX_STATE, CMD_FORCE_TRX_OFF);
    delay_us(tTR13);
    /* AT86RF212::TRX_OFF */
    config_regs.state = AT_trx_bit_read(SR_TRX_STATUS);

    AT_trx_reg_write(RG_TRX_CTRL_0, 0x19);
    AT_trx_reg_write(RG_TRX_STATE, CMD_FORCE_TRX_OFF);
    AT_set_default_regs();
    AT_set_spi_cmd_mode();
    AT_get_id();
    AT_phy_set_channel(DEFAULT_CHANNEL);

    AT_trx_bit_write(SR_TRX_CMD, CMD_PLL_ON);
    status=AT_get_pll_status()

 

In the above code, status always returns zero.

 

Does anyone have a suggestion of what else to try?

 

Thanks,

 

MikeH

 

This topic has a solution.
Last Edited: Fri. Oct 16, 2015 - 12:47 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

Why do you keep reset pin low after 1 us delay?

NOTE: I no longer actively read this forum. Please ask your question on www.eevblog.com/forum if you want my answer.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Alex,

 

The boolean values of "true" and "false" in this case refer to true = 0 (asserted) and false = 1 (not asserted) for the reset pin (only).

Last Edited: Tue. Nov 4, 2014 - 07:04 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

It is hard to say what is hidden behind all the functions. Download LwMesh and take initialization code from there. It is known to work.

NOTE: I no longer actively read this forum. Please ask your question on www.eevblog.com/forum if you want my answer.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Alex,

 

Thanks for the suggestion. But I have already downloaded LwMesh and spent hours going through the code and do not see a specific initialization sequence for the RF212B. Can  you point this out to me?

 

FYI, the code above is (almost) directly out of the Software Programming Model.

 

Thanks,

 

MikeH

 

Last Edited: Tue. Nov 4, 2014 - 07:22 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

LwMesh_1_2_1\phy\at86rf212\src\phy.c. AT86RF212 and AT86RF212B are virtually the same device.

 

There are may things that can be wrong here. For example, you set CMD_FORCE_TRX_OFF, but never wait for completion.

NOTE: I no longer actively read this forum. Please ask your question on www.eevblog.com/forum if you want my answer.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

In case of a new designed board, I would check the hardware.

 

Here are some questions, that may lead to the solution:

 

 - Is voltage correct, how much current is flowing?

 - how does the SPI signals look?

 - Is the xtal connected right?

 

FORCE_TRX_OFF is not needed, it makes things not better. The intention of FORCE_TRX_OFF is to cancel

ongoing transmits or receives (*_BUSY states).

 

 - The sense of the implemented reset procedure is not clear to me. Normally it is Ok to assert reset, keep it low and then deassert it.

 

 - What result do you read from register TRX_STATUS? is config_regs.state  == TRX_OFF?

 

 - What is the reason for the statement     AT_trx_reg_write(RG_TRX_CTRL_0, CLKRST);? If the reset line is working then there is

  no need to write reset values back to registers.

 

Hth, Axel.

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi Uracolix,

 

Thanks for taking a look at my problems.

 

- Is voltage correct, how much current is flowing?

DEVDD = +3.3v

EVDD = +3.3v

IVDD (P_ON) ~= 2mA, but some of this is used in the FEM.

IVDD (PLL_N) cannot measure because PLL does not come on.

 - how does the SPI signals look?

The SPI snapshot below shows the reset pulse (~2.3us) and the first two commands:

    AT_trx_reg_write(RG_IRQ_MASK, TRX_IRQ_PLL_LOCK);
    AT_trx_bit_write(SR_TRX_CMD, CMD_TRX_OFF);

Note that in the bit_write command, I first read the value of the register, manipulate the appropriate bits, then re-write the register.

 

 

 - Is the xtal connected right?

Here is a shot of the crystal layout with the solder paste layer turned on to help see the component footprints.

 

FORCE_TRX_OFF is not needed,

Yeah, I'm not sure why I put that in there. I was probably trying to debug something. It has been removed. 

- The sense of the implemented reset procedure is not clear to me. Normally it is Ok to assert reset, keep it low and then deassert it.

I agree. My implementation is a bit confusing ("true" and "false"), but the SPI snapshot shows it is operating correctly.

 What result do you read from register TRX_STATUS? is config_regs.state  == TRX_OFF?

I generally read the correct TRX_STATUS (i.e. TRX_ STATUS = TRX_OFF (0x08)) for each state change command. But again, the PLL is not on.

 What is the reason for the statement     AT_trx_reg_write(RG_TRX_CTRL_0, CLKRST);?

This is from the Atmel Software Programming Model example of POWER_ON_RESET which shows the following example code:

 

I have found that AVDD does not turn on (i.e. AVDD=0v) after the command AT_trx_bit_write(SR_TRX_CMD, CMD_PLL_ON); I have also tried     AT_trx_bit_write(SR_TRX_OFF_AVDD_EN, 1); and then checked the     reg=AT_trx_bit_read(SR_VREG_AVDD_OK); but the SR_VREG_AVDD_OK bit is 0. So something is wrong with AVDD, which means the PLL will not turn on.

 

Do you have any idea why AVDD would not turn on properly?

 

Thanks again for the help.

 

MikeH

 

 

 

Last Edited: Wed. Nov 5, 2014 - 01:59 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Ok, so the prerequisites look good.

 

Oops, the obfuscated reset code is a sort of boomerang (or in other words, life is not like a box of chocolate, it is more like jar of jalapenos, what you do today burns your a* tomorrow ;-)) ... I think the intention was to show that the levels at the GPIOs shall be stable.

 

What do you measure on DVDD?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

What do you measure on DVDD?

DVDD = +1.8V 

Last Edited: Thu. Nov 6, 2014 - 04:40 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

> IVDD (P_ON) ~= 2mA, but some of this is used in the FEM.

 

Can you somehow measure the RF212 isolated. It should have ~ 300µA when not in PLL_ON.

 

What does happen with the current when you issue the PLL_ON command?

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Can you somehow measure the RF212 isolated.

I was able to isolate the RF212 for current measurements: IVDD (P_ON) = 824uA after power on reset. This is a bit higher than the datasheet which says 550uA.

What does happen with the current when you issue the PLL_ON command?

No change. 824uA.

 

Perhaps I blew the AVDD regulator when trying to make a measurement.  However, both radio boards exhibit the exact same problem. And I would assume the smart engineers at Atmel have included a short-circuit protection mechanism on these regulators, especially since they are brought out on a pin.

 

Any other thoughts before I perform surgery on the RF212?

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

One new piece of information. After issuing a command to turn off CLKM (AT_trx_reg_write(RG_TRX_CTRL_0, CLKM_NO_CLOCK), the IVDD drops to 776uA.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Bit the bullet and replaced the RF212. 

IVDD (P_ON, RST deasserted) = 616uA.

 

After issuing a CLKOFF, IVDD drops to 566uA, which closely matches the data sheet at 3.3v.

 

However, after issuing a SR_TRX_OFF_AVDD_EN=1, the AVDD is still zero volts.

And after issuing a CMD_PLL_ON, the IVDD is still 566uA, and the AVDD is still zero volts.

 

WFT?

 

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Mike, could you post the schematics or send it to me via EMail (axel at uracoli dot de)? Will have a look at it tomorrow, now its quite late here.

 

Axel.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Axel,

 

Will do. I appreciate your help.

 

MikeH

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Just to keep this thread going (until I have a solution hopefully) I am posting some email exchanges on the issues/tests:

========================================================================

 

"1) The ferrite L2. Maybe if it has too high resistance, this may lead to ground bouncing, when a current is drawn if the analog part

is switched on."

I copied the Atmel eval board design.

 

“- go to state TRX_OFF and verify if you read value 8 (TRX_OFF) from TRX_STATUS.”

Correct. I get a value of 0x08 from TRX_STATUS.

 

“- then measure current”

Measured 616uA

 

“- set bit TRX_OFF_AVDD_EN = 1

-        measure current => you should see 80 to 100µA more.”

Still measure 616uA. No change. No voltage on AVDD.

 

“3) Check if there is a short-cirquit on cap C18 (AVDD cap.).”

Checked. No short.

 

“What type of Balun do you use?

If it has a DC decoupling to ground this might be wrong.”

The Balun is the Johanson 0896FB15A0100. The same balun used on the Atmel eval board. Here’s the internal schematic from Johanson. No DC path to ground. DC path is blocked on the out put with C11 (100pF).

 

“5) Since you see the same effects on two new PCBs, check if the wiring

is really OK - the schematic is OK, but maybe something bad happened during

manufacturing of the boards.”

Checked the PCB for shorts and found none.

 

Still baffled.

 

Last Edited: Thu. Nov 6, 2014 - 04:28 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Next steps tried;

 

1. Set VREG_CTRL bit AVREG_EXT = 1; 

2. Do NOT apply an external voltage to the AVDD pin.

3. Read VREG_CTRL. The AVDD_OK pin is now HIGH (1). How can this happen when there is still NO voltage on this pin?

FYI... VREG_CTRL value is 0xC4 (AVDD=EXT, AVDD=OK, DVDD=OK);

4. Applied an external +1.8V on AVDD.

5. Read VREG_CTRL. Value is still 0xC4;

6. Tried to start PLL. PLL will not start.

 

7. Remove Balun;

8. Repeat steps above. No change. PLL will not start.

 

9. Remove L2 and replace with zero ohm resistor.

10. Repeat steps above. No change. PLL will not start.

 

 

Last Edited: Thu. Nov 6, 2014 - 04:37 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Whats come to my mind just now:

 We should check if the SPI write command implementation is working ...

 So write 0xaa or any other pattern to e.g. register SHORT_ADDR_0 (0x20)

 and try to read the pattern back.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Alex,

	AT_trx_reg_write(RG_SHORT_ADDR_0, 0xaa);
	reg=AT_trx_reg_read(RG_SHORT_ADDR_0);
	AT_trx_reg_write(RG_SHORT_ADDR_0, 0x55);
	reg=AT_trx_reg_read(RG_SHORT_ADDR_0);

Readback results are 0xaa and 0x55. Looks OK.

Thanks again.

 

MikeH

 

 

Last Edited: Thu. Nov 6, 2014 - 08:15 PM
This reply has been marked as the solution. 
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

All,

 

 

So.....after 3 days of chasing my tail,     AT_trx_bit_write(SR_TRX_CMD, CMD_TRX_OFF);  IS REQUIRED early in the initialization routine, even after a power on reset sequence. Don't ask me why, but it now works.

 

Thanks Alex for helping me think this though.

 

MikeH