CC1352P: CC1352P Rev E resetting with CLK_LOSS

We had this issue at room temperature for the first prototypes of the launchpad.  I believe the issue was non ideal matching. Is your board following the latest reference designs fully?  

Edit: It was found that grounding the RXTX pin in RX resolved the issue. See the following section from the smartrf_settings file:

// Overrides for CMD_PROP_RADIO_DIV_SETUP_PA
uint32_t pOverridesTx20[] =
{
    // The TX Power element should always be the first in the list
    TX20_POWER_OVERRIDE(0x001B8ED2),
    // The ANADIV radio parameter based on the LO divider (0) and front-end (0) settings
    (uint32_t)0x11C10703,
    // override_phy_tx_pa_ramp_genfsk_hpa.xml
    // Tx: Configure PA ramping, set wait time before turning off (0x1F ticks of 16/24 us = 20.3 us).
    HW_REG_OVERRIDE(0x6028,0x001F),
    // Set TXRX pin to 0 in RX/TX and high impedance in idle.
    HW_REG_OVERRIDE(0x60A8,0x0001),
    (uint32_t)0xFFFFFFFF,
};

Our design follows the TI LAUNCHXL-CC1352P1 almost identically with the following exceptions:

• removed TIVA chip and bring out JTAG signals to program with our own JTAG interface/software
• 8pf tank caps for the 48MHz XTAL we used (ABM12W-48.0000MHZ-7-D1X)
• used values for the RF matching circuit on the PA from https://e2e.ti.com/support/wireless-connectivity/sub-1-ghz/f/156/p/783274/2908871#2908871

What do you mean by non ideal matching? Are you referring to layout or component values on the RF side?

My pRegOverrideTx20 struct is already identical as what you've posted here coming from SmartRF Studio 2.14.0 for CC1352P Rev E (2.1).

How are the overrides determined? When I was working with the CC1352P Rev 1.1 silicon a couple of months ago using then current SmartRF Studio version 2.11.0 it exported a lot more overrides for CMD_PROP_RADIO_DIV_SETUP_PA than the latest version I'm working with now with the CC1352P Rev 2.1 SmartRF Studio version 2.14.0.

How can I determine exactly what CLK has faulted?

Tim

I see now that the issue is not related to what we saw. Ee only saw some issues with the 32 kHz if sending with above 17 dBm. But I see that you have "few that reset upon receiving or transmitting" indicating that your issue is not related to high output power.

Do you get this issue if you use on of the RF examples unmodified from the SDK?