RFA1 PLL unlock?

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

Hey everyone!

 

I'm running the RFA1 on several nodes with custom firmware.  Most of their time is spend in RX_AACK mode.  Everything works great for a while, but after a day or so, some of my nodes stop receiving. I can see that the CPU is running, regulator voltages are ok, radio registers appear to be fine (I can peek/poke over a USB port).  However, I start getting a lot of PLL_UNLOCK interrupts, which generally never occur when things are working properly.

 

I'm running the filter tuning loops every two minutes.  I also periodically cycle the radio through TRX_OFF and then back into receive mode.  A reboot corrects the problem, so it seems like there is something internal to the radio that gets corrupted and starts preventing the PLL from locking.

 

I've searched high and low for any guidance on what to do with a PLL_UNLOCK interrupt.  I haven't seen any code other than mine that actually enables it.  The datasheet just says it indicates an unexpected PLL unlock (obviously), but gives no hints on what to do about it.

 

Anyone have any thoughts?

 

 

 

 

Last Edited: Fri. Oct 16, 2015 - 12:28 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

Check that you have sufficient decoupling capacitors.

 

Do you have any power electronics on the same board or in close proximity?

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

alexru wrote:

Check that you have sufficient decoupling capacitors.

 

I have the datasheet recommended 4x 1uF 0603, placed about as close to the IC as possible.  I'm running off of a 3.3 volt LDO, so my power net should be pretty clean, but I can check it with a scope tomorrow and see if there's a smoking gun.  Maybe AVCC can brownout and corrupt some internal state registers?

 

alexru wrote:

Do you have any power electronics on the same board or in close proximity?

 

One of the boards drives a pretty long string of LEDs (PWM).  But one of the others just runs a motion sensor (<1 mA) and is pretty far from anything else.

 

I'm curious as to why cycling through TRX_OFF and back to PLL_ON doesn't get it going.  I might try doing a full reset and re-init of the radio in my PLL_UNLOCK handler.  I think that's hacky, but it's better than a power cycle or full reboot, and would at least be a clue.

 

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

If possible, put a scope to trigger on a window and put a reasonably narrow window on a power supply rail and let it run until it locks.

 

What exactly happens when you go from TRX_OFF to PLL_ON?

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

alexru wrote:

If possible, put a scope to trigger on a window and put a reasonably narrow window on a power supply rail and let it run until it locks.

 

I'll try this tonight.

 

 

alexru wrote:

What exactly happens when you go from TRX_OFF to PLL_ON?

 

I busy wait during STATE_TRANSITION_IN_PROGRESS (with a timeout in case we get stuck here).  Then I check that TRX_STATUS matches the requested state, and log an error if not.  When I'm transmitting (so, going into PLL_ON), I also do a busy wait for the PLL_LOCK interrupt, also with a timeout and log message.  I don't see any error conditions on these transitions.

 

It's a bit complicated, because I use every mode of the transceiver to facilitate several different communication modes.  Most of the time I'm in RX_AACK_ON, but periodically I will do a FORCE_TRX_OFF, then a FORCE_PLL_ON, then RX_ON, wait a while, and then back to RX_AACK_ON.  This code path apparently does not wait for the PLL_LOCK flag, and I think this is where the PLL_UNLOCK starts occurring after a while.  I do need to look a bit deeper and make sure I know exactly where that occurs (the log message is in the IRQ handler so it does not know what code path triggered it).

 

I think the FORCE_TRX_OFF and FORCE_PLL_ON combination should be triggering a constant restart of the AVDD regulator and the PLL.  So I would think that whatever error state they get in, they would recover on the next transition, but they don't.

 

 

Looking at the datasheet, it seems that Atmel does not indicate a valid state transition between RX_AACK_ON and RX_ON.  Maybe this is a problem?  Also something I will look at tonight.

 

 

 

 

 

 

 

 

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

I've never used FORCE_PLL_ON, and I would stay away from it. It is absolutely not clear what it is doing.
 

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