MC13213 & MAC/PHY codebase - Noise issue?

[Spell]

I built a custom board using MC13213 for lighting application. I use a relays for switch on and off the lamp. Sometimes, after swtich on or off the lamp, the modem stops to work and restart after 4 minutes and sometimes never restart, I must reset manually the board. I suppose that problem is caused by an interference with the lamp switching circuit because without lamp this problem doesn't happen. Can this delay depends on a software timeout? And is it programmable? Can I check if the modem stops to work properly by some status registers or something else? Thank you, Filippo

Message Edited by Spell on 2008-12-09 09:52 AM

[RichTestardi]

If the modem goes idle after a repeatable period, you might have an issue with timer comparator 3 expiring, as listed in the errata, below.  Typically this will happen after 67 seconds, but could also happen 2x, 4x, 8x, or 16x after that.  To fix the bug, be sure to enable timer comparator 3 interrupts and restart the receiver when it pops.  To help identify if this is the case, you can enable the Out of Idle indicator and see if the transceiver gets stuck idle.

Timer Comparator 3 can abort an RX sequence - If an RX

sequence (Packet Mode) is active and Timer Comp 3 matches

the value of the Event Timer “current time” counter, the RX

sequence will be aborted. No status bit is set and no interrupt can

be generated. Exit from RX mode can only be detected by using

GPIO1 as an “out-of-idle” indicator.

Freescale IEEE 802.15.4 MAC (and BeeStack) software already

deals with and compensates for this situation.

If users are writing their own software (such as using SMAC), this

condition should be compensated for.

Note:

The Freescale IEEE 802.15.4 MAC and

BeeStack (which uses the MAC) already

compensate for this condition.

For users writing their own applications:

a) Never let the counter reach the compare value

in Time Comp 3 register.

b) Enable Timer Compare 3 always to generate an

interrupt. If the interrupt occurs and the RX state

was enabled. Take appropriate action, such as

restarting RX.

c) Monitor the “out-of_idle” indicator while in RX

mode.

[Spell]

Thanks Rich T, I knew this kind of problem.
I'm using Freescale 802.15.4 MAC/PHY codebase so I thought to be ok.

Anyway the Reference Manual suggests to enable the tmr_cmp and the interrupt but in the modem initialization routine I found the interrupt is disable.

I have to manually enable it?

thanks,
filippo

[RichTestardi]

I'm not familiar with that codebase, so they might have worked around the bug using one of the other methods, or in another way, so this very well may not be your problem.  Can you dump all of the transceiver registers before and after the "hang"?

I believe the easiest way to tell if this is the issue is to enable the "Out of Idle" indicator on pin 44 (assuming pins 43 and 44 are amenable to this in your circuit and MCU configuration -- see table 3-2 in the Reference Manual) and monitor it to see if the transceiver mysteriously goes idle when the issue arises -- mine always went idle after exactly 67 seconds (see table 6-1 for possible timer periods, multiples or fractions of 67 seconds).  Alternately you could also try changing the timer 3 compare value and see if the problem occurs after a different amount of time.