Problem with MC13213 initialization

[PedroMietto]

Hi guys. I'm quite new to this forum, and I really hope you could help me here.

I'm developing a custom 802.15.4 solution, based on the 1321x-SRB reference, including schematic, layout and firmware. I'm using a MC13213 and loading the BeeKit PER firmware.

The problem I'm having here is that I can't get the CPU past the initialization routine, and using the BDM I can see that the CPU stays in this loop:

while(u8AttnIrq == FALSE)
    {
        if(IRQFLAG == 1) {     
            /* Check to see if IRQ is asserted */
            u16IrqReg = SPIDrvRead(0x24);   /*
                                             * Clear MC13192 interrupts and 
                                             * check for ATTN IRQ from 13192
                                             */
            u16IrqReg &= 0x400;
           
            if(u16IrqReg == 0)
                u8AttnIrq = FALSE;
            else
                u8AttnIrq = TRUE;
        }
    }

More specifically, the IRQFLAG never gets asserted by the hardware, and that locks the program forever.

I searched here for solution, and I found people having the exactly same problem, and it was related to soldering issues. I'd like to know if you had this problem and found another solution, or maybe if you could direct me, or try to explain when this flag gets asserted and why it's not working properly.

Here we have an x-ray machine and it really helps in finding soldering issues, but even with that, sometimes you can't be 100% sure. This a very annoying IC to deal with.......

I could upload the schematic, but it's exactly the same as another board we've designed here.

Another thing I saw here is a problem concerning the crystal. I'm using one that certainly has a load capacitance above the 9pF required, but I already sucessfully used this component on another board, with MC13213. Is it possible that with a little different layout it stops working?

[Spell]

Hi Pedro,
I had your same problem and it was a soldering issue in the test point under the micro. Some of this test point are connected with the SPI interface between micro and modem. So I suggest to you to make an x-ray test...

This is my test result:

Message Edited by Spell on 2007-10-18 10:58 AM

Photo4.jpg

Message Edited by t.dowe on 2009-10-27 01:38 PM

[PedroMietto]

Hmm....interesting Spell...

I think I'll mount a few more boards and try to assure they don't get soldering issues.....but the weird thing is that those test points don't even have a pad beneath then....so it's very strange they got shorted on the two boards I have mounted.

When we saw the test pads can get shorted too easily and that we wouldn't need to access to them during development, we decided, on the layout, to don't place pads for them, so they wouldn't get shorted and could fluctuate without problems....do you think maybe that's what is causing the problem? The missing pads under the test points?

Anyway, thanks for the help

Message Edited by Pedro Mietto on 2007-10-18 12:35 PM

[Spell]

---

Pedro Mietto wrote:

When we saw the test pads can get shorted too easily and that we wouldn't need to access to them during development, we decided, on the layout, to don't place pads for them, so they wouldn't get shorted and could fluctuate without problems....do you think maybe that's what is causing the problem? The missing pads under the test points?

---

If you didn't have place pads for test points the solder issue is impossible, the test pin mustn't be shorted so if yours are flotting it's ok.
Sorry, maybe you have a different problem....

regards, Filippo

[PedroMietto]

Ok, got it working past the initialization point. And indeed it was a soldering issue, as we mounted another board and the MCU seems to be ok. However, the transceiver is not. When I try to transmit or receive, the MCU crashes at this same point:

.......

gu8RTxMode = PULSE_TX_MODE;
SPIDrvWrite(MODE_ADDR, u16Reg);
RTXENAssert();

When trying to assert the RXTXEN pin, it locks and loses the frequency. I don't know why the program jumps to the PULSE_TX_MODE in both TX and RX mode, but the debugger shows that this is the crashing point.

I don't know if you can help me here, but I'm quite at loss for ideas. And again, I'm thinking this is a soldering issue....

[Brodek]

Hi!!

I've the same problem with the RXTXEN pin.

When I try to assert this pin high to transmit a frame the MC13213 loss the clock and reset.

How have you solved this problem?

If I put the same firmware on a demo-board it run without any problem.