Sub-1 GHz forum - Recent Threads

RE: CC1352R: CC1352R ROM code SRAM parity error handler taking precedence over custom vector table bus fault handler

Daryl Olsen — Fri, 09 Oct 2026 17:51:37 GMT

Hi Daniel,

I found the problem is flaw in our own software architecture of having two applications in our NVM: bootloader and application. The bootloader vector table was executing in response to the parity error first based on our CCFG settings for IMAGE_VALID etc. I am able to execute our custom handler in response to the fake ram parity error now that this is understood.

Issue resolved.

Thanks,
Daryl

CC1352R: CC1352R ROM code SRAM parity error handler taking precedence over custom vector table bus fault handler

Daryl Olsen — Thu, 08 Oct 2026 15:50:40 GMT

Part Number: CC1352R

I am working with custom CC1352R hardware for aerospace application.
I'm using the SRAM parity detection for SEU mitigation and would like to test it's handling behaviour.
To do so, I have written a externally triggered function call that creates a fake ram parity error using the PER_DEBUG_ENABLE bits in PER_CTL register. I'm setting a an offset in PER_DEBUG_ADDR in PER_DBG register, then writing and reading said adress to trigger the bus exception, i.e. inducing a fake parity error.

I have written my own vector table via .resetVecs section intended to be called in response to the bus exception. Inside my handler I intend to log a fault to NVM , then reset the processor.

Problem I'm having is when I execute with debugger this I find that some ROM code's FaultISR at ROM code address 0x100020C0 executes and resets the processor rather than my own vector table ISR.

I don't really understand why this is happening given I've disabled ROM bootloader through CCFG settings.
Is there some other method or CCFG setting that can modify this behaviour so my custom vector table executes in response to bus exception caused by SRAM parity error?

RE: CC1352R: CC1352R ROM code SRAM parity error handler taking precedence over custom vector table bus fault handler

Daryl Olsen — Fri, 09 Oct 2026 15:24:36 GMT

Hi Daniel,

This is a baremetal application that enters in a while(1) loop in main() after initializations are executed. We monitor peripherals and time various actions from within the while(1) using SysTick timer. We are using the NoRTOS kernel source code from SDK for various drivers , etc. But they all mainly use the Systick/TimerP drivers.
We used baremetal option SysCfg initially to populate our drivers for I2C, SSI, Flash, etc . But current code has no .a libraries from sdk included, only source ported locally to our CCS project.

Thanks,
Daryl

RE: CC1352R: CC1352R ROM code SRAM parity error handler taking precedence over custom vector table bus fault handler

Daniel Guarecuco Aguiar — Fri, 09 Oct 2026 15:12:36 GMT

Hi Daryl,

Is this baremetal, FreeRTOS or TIRTOS?

In the meantime, maybe this resources are useful

CC1352P7: Custom exception handler define - Sub-1 GHz forum - Sub-1 GHz - TI E2E support forums

CC3220SF: How to write my own Hard Fault Handler - Wi-Fi forum - Wi-Fi - TI E2E support forums

Best regards,

Daniel

RE: CC2340R5: CC2340R53 – Unexpected 2.2 mA Current Consumption in Shipment Mode After Long Runtime

desouza — Fri, 09 Oct 2026 13:23:35 GMT

Hi Hiren,

Thanks for the additional tests. A few answers:

[quote userid="680243" url="~/support/wireless-connectivity/sub-1-ghz-group/sub-1-ghz/f/sub-1-ghz-forum/1687555/cc2340r5-cc2340r53-unexpected-2-2-ma-current-consumption-in-shipment-mode-after-long-runtime/6504975"]Since we are on SDK 9.11.01.19, is the CKM_01 power-driver workaround already included?[/quote]

Yes, this should be the case indeed.

Does OAD / Power_reset() clear the debug subsystem (similar to pin reset / power cycle)?
Based on our soft-reset result, do you agree debug-domain latch is unlikely here?

[/quote]

I am not entirely sure how the OAD Power_reset() is implemented (I will ask a colleague of SW apps to interject here), but the software reset should not have reset the debug subsystem, so it seems that your "Test B" indeed rules out my initial theory. But I will test this locally and see if this is still the case.

[quote userid="680243" url="~/support/wireless-connectivity/sub-1-ghz-group/sub-1-ghz/f/sub-1-ghz-forum/1687555/cc2340r5-cc2340r53-unexpected-2-2-ma-current-consumption-in-shipment-mode-after-long-runtime/6504975"]Based on the CKMD register values above, do you agree LFXT / tracking-loss is unlikely here?[/quote]

I agree with you. The LFXT seems to be running normally based on the register values of "Test A".

[quote userid="680243" url="~/support/wireless-connectivity/sub-1-ghz-group/sub-1-ghz/f/sub-1-ghz-forum/1687555/cc2340r5-cc2340r53-unexpected-2-2-ma-current-consumption-in-shipment-mode-after-long-runtime/6504975"]What are the recommended next checks to identify why standby is not entered while BLE is still alive?[/quote]

I will have to ask a colleague in SW apps to interject here (I am a bit rusty on the BLE APIs these days).

[quote userid="680243" url="~/support/wireless-connectivity/sub-1-ghz-group/sub-1-ghz/f/sub-1-ghz-forum/1687555/cc2340r5-cc2340r53-unexpected-2-2-ma-current-consumption-in-shipment-mode-after-long-runtime/6505171"]LFCLKLOSS = 1 (this is the key finding from our side)[/quote]

This is interesting in your "Test C" which, according to the description of this bit (CKMD:RIS.LFCLKLOSS[12]), will cause the device to fall back to a less efficient way to generate the low frequency clock. As the description says, this is not the same as completely losing the LFXT but perhaps the external crystal might be unstable. I would re-check the 32kHz crystal load capacitors - check section 6 of the application note CC23xx and CC27xx Hardware Configuration and PCB Design Considerations

Additional information about the clock systems can be found at the application note Crystal Oscillator and Crystal Selection

In the light of these scenarios, I don't believe the crystal is being completely lost. As a test, however, you could enable the bit PMCTL:RSTCTL.LFLOSS[2] to trigger a reset and see if that would be the case.

[quote userid="680243" url="~/support/wireless-connectivity/sub-1-ghz-group/sub-1-ghz/f/sub-1-ghz-forum/1687555/cc2340r5-cc2340r53-unexpected-2-2-ma-current-consumption-in-shipment-mode-after-long-runtime/6505171"]Meaning of ROM PC 0x0F002D9A when entered from LL_PhyUpdateCompleteEventCback?[/quote]

I will have to ask the SW apps team to comment here.

[quote userid="680243" url="~/support/wireless-connectivity/sub-1-ghz-group/sub-1-ghz/f/sub-1-ghz-forum/1687555/cc2340r5-cc2340r53-unexpected-2-2-ma-current-consumption-in-shipment-mode-after-long-runtime/6505171"]Can this ROM/BLE path keep average current near ~2.2 mA while advertising/connection still work?[/quote]

There are quite a few ROM calls during normal execution of the code. What I usually do when the code is in ROM is open the Disassembly view, then perform a few "Assembly Step Into" operations to see if the code goes back to a point where the project's source code is present. This usually gives me confidence the code is still running normally.

[quote userid="680243" url="~/support/wireless-connectivity/sub-1-ghz-group/sub-1-ghz/f/sub-1-ghz-forum/1687555/cc2340r5-cc2340r53-unexpected-2-2-ma-current-consumption-in-shipment-mode-after-long-runtime/6505171"]How should we interpret LFCLKLOSS=1 with LFXT still selected and TRACKREFLOSS=0?[/quote]

I mentioned this in a few paragraphs above.

Hope this helps,

Rafael

CC2340R5: CC2340R53 – Unexpected 2.2 mA Current Consumption in Shipment Mode After Long Runtime

Hiren M Parmar — Wed, 07 Oct 2026 06:36:36 GMT

Part Number: CC2340R5

Description

We are using the TI CC2340R53 MCU in our battery-powered device. The firmware has two operating modes:

Active Mode
Shipment Mode

In Shipment Mode, almost all device functionality is disabled to minimize power consumption. The intended functionality in this mode is only:

BLE advertisement every 9.5 seconds
BLE advertisement data update every 1 hour
Store the device ON-time information in EEPROM
No other application functionality is expected to run continuously.

Expected Behavior

When the device enters Shipment Mode, we initially observe a current consumption of approximately 4–6 µA, which is within our expected range.

The MCU should remain in a low-power/sleep state between the scheduled BLE advertisements and other required operations.

Observed Issue

After the device remains in Shipment Mode for some period of time, the current consumption unexpectedly increases to approximately 2.2 mA.

The important point is that the timing of this increase is not deterministic.

For example, we cannot currently determine whether the issue occurs after a specific number of minutes, hours, or days. The device initially remains at approximately 4–6 µA, but at some unknown point later, it starts consuming around 2.2 mA continuously after this if we softrest or hard reset the device current back to noraml 4 to 6uA.

Once this occurs, the current does not return to the expected 4–6 µA range.

Our Concern

We suspect that the CC2340R53 may not be entering or remaining in the expected low-power state after some long-running operation.

Our current doubts are:

Is the MCU getting unintentionally woken up by some interrupt or peripheral?
Could a timer, RTC, BLE stack event, or other system event keep the MCU awake?
Could there be a low-power mode transition issue after repeated BLE advertisements?
Could some interrupt remain pending and continuously wake the MCU?
Could the BLE stack or another RTOS/system task prevent the MCU from returning to the expected sleep state?
Is there any known CC2340R53 issue where current consumption can increase after extended operation in a low-power/BLE advertising use case?
Is there any recommended method to determine which peripheral, interrupt, task, or wake-up source is responsible for the MCU remaining active?

Additional Information

The BLE advertisement interval in Shipment Mode is approximately 9.5 seconds.

The advertisement data is updated once every 1 hour.

Other than these operations and storing the required ON-time information in EEPROM, no application functionality is intentionally running in Shipment Mode.

The device initially achieves approximately 4–6 µA, so the hardware is capable of achieving the expected low-power consumption.

The problem appears only after the device has been running for an unknown amount of time.

Support Required

Could TI please guide us on how to debug this issue on the CC2340R53?

Specifically, we would like to know:

How can we determine whether the MCU is actually entering sleep/standby mode between BLE advertisements?
How can we identify the wake-up source when the unexpected 2.2 mA current occurs?
Are there recommended registers, debug APIs, power-management callbacks, or tools that can be used to identify why the MCU remains active?
Are there any known issues related to long-duration BLE advertising and low-power operation on CC2340R53?
Could repeated BLE advertising every 9.5 seconds eventually cause the BLE stack or another peripheral to remain active?
Are there any recommended low-power configuration checks we should perform to ensure the MCU always returns to the expected sleep state?

We can provide the relevant power-management, BLE advertising, timer/RTC, interrupt, and Shipment Mode firmware code if required.

Any guidance on how to systematically identify the source of the unexpected 2.2 mA current consumption would be highly appreciated.

LP-XDS110ET: When attempting to program a part with LP-XDS110ET what does the serial number LS420AIL signify?

Mark Butcher — Wed, 07 Oct 2026 15:23:49 GMT

Part Number: LP-XDS110ET

Hi All

We are working with the CC35X1 and the LP-XDS110ET as debugger. When working t^with teh develoment bpard it shows as serial number E100000U and all works.

We now have custom HW where we attempt to use teh debugger via its 10-pin JTAG/SWD connector but without any success.

We notice that the serial number LS420AIL is displayed (although the same is displayed when there is no development board connected).

Any attempt to program resuts in "Error with getting device info..."

What are recommendations to finding the problem here? We have connected SWD on out custom HW and don't see how to switch between JTA or SWD mode at the debugger (is it automated?).

Thanks for any advice.

Regards

Mark

RE: LP-XDS110ET: When attempting to program a part with LP-XDS110ET what does the serial number LS420AIL signify?

Alex Fager — Thu, 08 Oct 2026 16:17:38 GMT

Hello Mark,

Thank you for you update, glad to hear its working now.

Thanks,
Alex F

RE: CC1352R: CC1352R ROM code SRAM parity error handler taking precedence over custom vector table bus fault handler

Daryl Olsen — Thu, 08 Oct 2026 15:56:01 GMT

Attached is CCS debugger screenshot of single stepping this fake ram parity error:

RE: CC1352P: CC1352P1F3 custom board: Correct location for RF test connector / VNA to tune antenna pi-network (433 MHz)

RGW — Thu, 08 Oct 2026 12:47:57 GMT

Hi,

1. The connector should be positioned at point "A". What we normally do for tuning the boards is to lift the DC blocking capacitor (C32) and then use a semi-rigid cable connected to the right side of C32 pads to tune the antenna.

2. The balun only converts the differential RF pins to a single-ended signal; it does not produce 50 Ω by itself. The LC low-pass filter performs both harmonic attenuation and impedance transformation to 50 Ω. The impedance between the balun and the LC filter is not 50 Ω — it is an intermediate impedance that is part of the combined balun+filter design. All our RF designs are terminated to 50 ohm at the SMA — meaning the 50 Ω point is at the LC filter output, not at the balun output.

3. There's no reason to insert a connector between the balun and the LPF.

4. Do you have access to a VNA or spectrum analyzer ?

- Ideally, this should be done with a VNA and you can perform a S11 measurement. Indirectly, with a spectrum analyzer, if the output power is not as expected; then this can be an indicator that the impedance is far from 50 ohm.

CC1352P: CC1352P1F3 custom board: Correct location for RF test connector / VNA to tune antenna pi-network (433 MHz)

Franco Bolaños — Wed, 07 Oct 2026 18:06:52 GMT

Part Number: CC1352P

Hi,

I am designing a custom board with the CC1352P1F3 using the 433 MHz path copied from LAUNCHXL-CC1352P-4 (balun+ LC low-pass filter + 470 pF DC block). After the DC block I have an antenna pi-network and a helical antenna.

I want to tune the antenna pi-network with a VNA, where should I put its connector?

A) Connector after the LC filter and DC block, before the pi-network
B) Connector between the balun and the LC filter.

Questions:

Which location is correct for tuning the antenna pi-network with a VNA?
Is the impedance at the balun output / LC filter input specified as 50 ohm for the CC1352P 433 MHz reference design, or is the 50 ohm transformation done by the LC filter?
Would inserting a connector between the balun and the filter affect the reference design performance?
How could I check LC filter output is indeed 50 ohm?

Thank you.

RE: CC2340R5: CC2340R53 – Unexpected 2.2 mA Current Consumption in Shipment Mode After Long Runtime

Hiren M Parmar — Thu, 08 Oct 2026 12:28:24 GMT

Hi Rafael,

Follow-up with results from the next stuck unit (~2.2 mA). Captured by halt only (no reset/flash).

Additional findings

Power constraintMask = 0 → DISALLOW_STANDBY / DISALLOW_IDLE not set
Halted PC repeatedly at 0x0F002D9A (ROM/HAPI)
LR/stack in BLE path: LL_PhyUpdateCompleteEventCback and SM-related frames
I2C handle = NULL; UART0 UARTEN = 0
Clock status on this unit:
- LFCLKSEL = LFXT
- TRACKREFLOSS = 0
- LFCLKGOOD = 1
- LFCLKLOSS = 1 (this is the key finding from our side)
SWDCK (DIO17) IOC pull configured as pull-down (not pull-up)
Soft reset previously restored 4–6 µA on another stuck unit

Updated interpretation
Debug-domain latch and a simple app Power-constraint latch look unlikely (constraintMask = 0, soft reset recovers).
Evidence now points more to the CPU remaining active in TI ROM via BLE LL/SM path, with possible LF clock-loss involvement on some units.

Please advise

Meaning of ROM PC 0x0F002D9A when entered from LL_PhyUpdateCompleteEventCback?
Can this ROM/BLE path keep average current near ~2.2 mA while advertising/connection still work?
How should we interpret LFCLKLOSS=1 with LFXT still selected and TRACKREFLOSS=0?
Recommended next registers/APIs to dump in this exact state (before reset)?

Thanks,
Hiren

RE: CC2340R5: CC2340R53 – Unexpected 2.2 mA Current Consumption in Shipment Mode After Long Runtime

Hiren M Parmar — Thu, 08 Oct 2026 09:19:08 GMT

Hi Rafael,

Thank you for the guidance. We completed further tests on a device stuck at ~2.2 mA in Shipment Mode. Below is a combined update with our observations and results.

Setup

Device: CC2340R53
SDK: simplelink_lowpower_f3_sdk_9_11_01_19
Board LF clock: external 32.768 kHz LFXT
Mode: Shipment Mode (BLE advertising ~9.5 s)
Symptom: current initially ~4–6 µA, later stuck near ~2.2 mA

Functional observations while stuck

BLE advertising still works.
BLE connection still works.
Shorting nRESET to GND recovers current to ~4–6 µA.
BLE OAD update (same firmware version) also recovers current to ~4–6 µA after the OAD reboot.

Clarification we had on reset type In our firmware there is no dedicated BLE soft-reset command. OAD uses OAD_PROFILE_MSG_RESET_REQ and performs an application reboot after download.

As we understand:

Debug subsystem remains powered until pin reset or system power-down
A normal CPU soft reset (NVIC_SystemReset) should not clear the debug subsystem
OAD / Power_reset() may behave like a harder reboot

So we specifically performed a pure soft-reset test as well.

Test A – Clock / LFXT status while stuck (before any reset)
We halted the running target (no flash reload) and read:

CKMD_RIS @ 0x40001048 = 0x0003E6E5
- TRACKREFLOSS = 0
- TRACKREFOOR = 0
- LFCLKGOOD = 1
- LFCLKOOR = 0
- LFCLKLOSS = 0
CKMD_LFCLKSEL @ 0x400010C0 = 0x0000000A
- MAIN = 2 → LFXT selected
CKMD_TRACKSTAT @ 0x400010EC = 0x80040241
- tracking valid (LOOPERRVLD = 1)

Current remained high during this check (~2.3 mA with debugger attached; ~150 µA attributed to debugger).

Test B – Pure soft reset
We issued Cortex-M SYSRESETREQ via AIRCR (0xE000ED0C = 0x05FA0004), equivalent class to NVIC_SystemReset
(not pin reset, not battery remove, not OAD / Power_reset).

Result: current returned to expected ~4–6 µA.

Current interpretation

Soft reset alone restored 4–6 µA → debug-subsystem latch appears unlikely for this case.
LFXT selected and no TRACKREFLOSS / LFCLKLOSS while current was high → LFXT / CKM tracking-loss also appears unlikely for this case.
We currently suspect something in software / power management is keeping the device out of standby (power constraint, task/ISR path, etc.), which is cleared by soft reset.

Please confirm / advise

Since we are on SDK 9.11.01.19, is the CKM_01 power-driver workaround already included?
Does OAD / Power_reset() clear the debug subsystem (similar to pin reset / power cycle)?
Based on our soft-reset result, do you agree debug-domain latch is unlikely here?
Based on the CKMD register values above, do you agree LFXT / tracking-loss is unlikely here?
What are the recommended next checks to identify why standby is not entered while BLE is still alive? For example:
- Power_getConstraintMask()
- PowerLPF3_isLfincFilterAllowingStandby()
- Power notify callbacks
- any other register/API for wake source / constraint identification

On the next stuck unit, we will capture Power_getConstraintMask() and call-stack information before resetting.
We can also share schematic details around SWDCK and LFXT if needed.

Kind Regards,
Hiren

RE: LP-XDS110ET: When attempting to program a part with LP-XDS110ET what does the serial number LS420AIL signify?

Mark Butcher — Wed, 07 Oct 2026 23:25:22 GMT

Thank you Alex

The LS420AIL now makes sense.

Fortunately we have just managed to solve the issue of connection to the wifi module - it was a missing pull-up on the RST line (with a weak pull-down causing problems) which meant that the RST was never going high correctly - presumably the RST drive from the debug module is open-drain and so couldn't pull it high.
After adding the pull-up the operation became successful.

Regards

Mark

RE: LP-XDS110ET: When attempting to program a part with LP-XDS110ET what does the serial number LS420AIL signify?

Alex Fager — Wed, 07 Oct 2026 21:28:21 GMT

Hello Mark,

I will comment on the XDS110, the CC35X1 is a WI-FI part though so a new thread might be needed.

[quote userid="721093" url="~/support/wireless-connectivity/sub-1-ghz-group/sub-1-ghz/f/sub-1-ghz-forum/1687719/lp-xds110et-when-attempting-to-program-a-part-with-lp-xds110et-what-does-the-serial-number-ls420ail-signify"]We notice that the serial number LS420AIL is displayed (although the same is displayed when there is no development board connected).[/quote]

This is the info of the XDS110 itself not of the target device (CC35), as you noticed even if no development board is connected this info is still maintained.

[quote userid="721093" url="~/support/wireless-connectivity/sub-1-ghz-group/sub-1-ghz/f/sub-1-ghz-forum/1687719/lp-xds110et-when-attempting-to-program-a-part-with-lp-xds110et-what-does-the-serial-number-ls420ail-signify"]What are recommendations to finding the problem here? We have connected SWD on out custom HW and don't see how to switch between JTA or SWD mode at the debugger (is it automated?).
[/quote]

If you are having trouble specifically with the CC35x1 please create a new thread in the WI-FI section detailing your current issue/observations.

Thanks,
Alex F

RE: CC2340R5: CC2340R53 – Unexpected 2.2 mA Current Consumption in Shipment Mode After Long Runtime

desouza — Wed, 07 Oct 2026 18:33:10 GMT

Hi,

Thanks for the very thorough and detailed post.

Per your description, my strongest suspicion is the debug subsystem might be powering up inadvertently - this subsystem typically draws 1~2mA when powered up and can only be powered down by a pin reset or a system power down. The reasons why this happens greatly vary but are highly dependent on the environment surrounding the product. Typically, if the product is subjected to an environment with strong EMI, the chances of this happening are higher.

A way to greatly reduce this possibility is to place a pull up resistor on the SWDCK pin of the device.

Naturally, since we are not present in your environment, this is mostly speculative especially due to the fact that CC2340R5 family of devices was hardened when compared to previous device families.

Another issue could be a random failure of the low frequency crystal (if you are using one). The low frequency crystal (32kHz) is responsible for accurate timekeeping during standby modes and any failures might be waking up the device. One additional aspect related to the low frequency crystal is an errata that is related to the SDK release you are using. Please check the reference below:

CC2340R5: Inquiry about Importance of CKM_01 Erratum and Standby Handling in CC2340 with HFXT (simplelink_lowpower_f3_sdk_8.40.00.61)

Hope this helps,

Rafael

RE: CC1120: Crystal drive level.

RGW — Wed, 07 Oct 2026 10:42:21 GMT

Hi,

Can you ask for the mutual inductance (Lm) parameter which is missing from the crystal datasheet ?

Looks like on mouser they will receive many xtals in November (https://mou.sr/4i6k95E):

14,750 Expected 16/11/2026

39,000 Expected 23/11/2026

66,000 Expected 23/12/2026

On Digikey 3000 are expected 04/11/2026 (www.digikey.com/.../5209190)

CC1120: Crystal drive level.

Callum Bassie — Mon, 05 Oct 2026 14:38:19 GMT

Part Number: CC1120

What is the CC1120s crystal drive level? We currently use the epson crystal which supports 200uW max. I would like to use a crystal that has a 100uW drive level. Will this be ok?

CC1352R: Smart RF Flash Programmer Tool ECCN (EAR Classification)

Brandon Cedarblade — Tue, 06 Oct 2026 14:20:49 GMT

Part Number: CC1352R

What is the Export Classification Control Number (ECCN) of the SmartRF Flash Programmer v2 1.8.2 (Jul 5, 2020)?

RE: CC1352R: Smart RF Flash Programmer Tool ECCN (EAR Classification)

desouza — Tue, 06 Oct 2026 19:26:51 GMT

Hi,

The file <SmartRF_Flash_Programmer-2_1.8.2_manifest.html> contains this information.

This file is part of the Windows SmartRF Flash Programmer installer .zip file, which can be downloaded from its page below:

https://www.ti.com/tool/FLASH-PROGRAMMER

Hope this helps,

Rafael

RE: CC1120: Antenna matching

RGW — Tue, 06 Oct 2026 17:00:34 GMT

Yes, this will be fine.

CC1120: Antenna matching

Callum Bassie — Mon, 05 Oct 2026 14:45:16 GMT

Part Number: CC1120

The CC1120 states the following in the datasheet. Does this mean I must match my antenna to the stated impedance?

Same here; does the following refer to the external components on the RX/TX circuits or is this for the antenna? Is it safe to presume that the reference design meets the requirements below?

RE: CC1120: Antenna matching

Callum Bassie — Tue, 06 Oct 2026 07:40:55 GMT

Hi,

So, on the presumption that the reference design has been used. should I just place a PI network close to the antenna and match it to 50 ohms once it is in its complete operating environment?

RE: CC1120: Crystal drive level.

Callum Bassie — Mon, 05 Oct 2026 16:57:53 GMT

Hi,

See attached.
https://portal.iqdfrequencyproducts.com/products/pn/LFXTAL073170.pdf

The Epson crystals are becoming hard to source. Can you recommend any alternatives?

RE: CC1120: Crystal drive level.

RGW — Mon, 05 Oct 2026 16:51:17 GMT

The CC1120 datasheet does not explicitly define a maximum crystal drive level in microwatts.

Regarding your specific question about the 100 µW drive level: if your crystal meets the ESR, load capacitance requirements and maximum ESR of 60 ohm; a 100 µW rating is generally sufficient for the CC1120’s oscillator drive strength. The internal oscillator circuit is designed for low-power operation, and it is standard practice to use crystals with drive levels in the 50 µW to 200 µW range.

Can you post the datasheet of the crystal ?