CC1352P: CC1352P Rev E resetting with CLK_LOSS or hanging on EasyLink_Params_init()

Intellectual 525 points

Replies: 24

Views: 288

Part Number: CC1352P

Our board design is based off the CC1352P1_LAUNCHXL, the obvious changes from the launchpad include:

 - we remove the TIVA chip and add a JTAG connector (we program it with our own JTAG dongle)

 - we use an Abracon ABM12W-48.0000MHZ-7-D1X-T3 crystal (48MHz, 7pF load capacitance, -40 to +85C temp, +/-10ppm Freq tolerance, +/-20ppm Freq stability)

I'm using CC1352P revE chips and simplelink_cc13x2_26x2_sdk_3_20_00_68 with examples/rtos/CC1352P_4_LAUNCHXL/easylink/rfEasyLinkNp.

I've got 20 prototype boards and so far it appears that every one of the eventually experiences one of two different issues using unmodified rfEasyLinkNp application:

- AT+I 1 EasyLink_Params_init(50kbps2gfsk) will hang

- AT+TX <msg> (EasyLink_transmit()) will cause a chip level reset where SysCtrlResetSourceGet indicates CLK_LOSS as the reason

When a board gets into one of the above cases (which it seems to do sometimes after 10000+ successful TX/RX packets) it seems to stick in this case for quite some time even after power cycles (as in power cycle the board and it will hang on the first AT+I or reset on the first AT+TX like a latch-up condition).

I expect an issue with the 48MHz crystal so have started exploring different capacitor values (we use 8pf caps in the tank and I've been told that the CC1352P1_LAUNCHXL uses 7.5pf) including removing the caps and using the internal array... nothing has made a markable difference.

I would like to understand how to determine which clock triggered the CLK_LOSS in case its not the 48MHz. I'm reading the following registers after the chip comes out of reset and after I've initialized the UART:

STAT0:0x00000006
STAT1:0x0000001a
RESETCTL:0x00003bea

The reference manual states that in order to trigger a reset on CLK_LOSS you need to set both DDI_0_OSC:CTL0.CLK_LOSS_EN and AON_PMCTL:RESETCTL.CLK_LOSS_EN which is not enabled after boot. I don't enable these yet I find they are both enabled (why?). I have tried to disable them with the following code added in rfEasyLinkNp.c:atnpFxn() but the reset still occurs (why?).

uint32_t reg = HWREG( AON_PMCTL_BASE + AON_PMCTL_O_RESETCTL );
uart_printf("RESETCTL:0x%08lx\r\n", reg); // shows 0x00003bea
reg &= ~AON_PMCTL_RESETCTL_VDDS_LOSS_EN;
HWREG(AON_PMCTL_BASE + AON_PMCTL_O_RESETCTL) = reg;
uart_printf("RESETCTL:0x%08lx\r\n", HWREG(AON_PMCTL_BASE + AON_PMCTL_O_RESETCTL)); // shows 0x00003aea

HWREG(AUX_DDI0_OSC_BASE + DDI_O_CLR + DDI_0_OSC_O_CTL0 ) = DDI_0_OSC_CTL0_CLK_LOSS_EN;
printf("DDI_0_OSC_CTL0:0x%08lx\r\n", HWREG(AON_PMCTL_BASE + AON_PMCTL_O_RESETCTL)); // shows 0x00003aea

Please advise. This issue has been plaguing me for weeks and I'm unable to ship product because of this instability. Please do NOT close this thread if you don't hear from me in a day... that does NOT mean the issue is resolved, it just means I haven't been able to get back to it.

24 Replies

  • In reply to TER:

    The stack-up we use is detailed in the 'FAB' file within the gerber zip file I sent.

  • Guru 248415 points

    In reply to Tim Harvey9:

    Could you "translate" the .FAB file for me? 

    It's not easy for me to see which part of that file that describe the stack-up.

     OOO until November 25th

  • In reply to TER:

  • Guru 248415 points

    In reply to Tim Harvey9:

    I woke up at 2 AM today to realize that my last post should have been erased... 

    But as far as I see this is the stack-up we recommend, it's the distance from layer1 to layer2 that is the important parameter here. 

     OOO until November 25th