Other wireless technologies forum - Recent Threads

CC2651R3: Enable power down mode

Reshmi senan — Fri, 14 Aug 2026 07:01:20 GMT

Part Number: CC2651R3

Dear sir,

I am developing a project using the CC2651R3 microcontroller. I need to implement a low-power routine where the device enters a 30-second sleep mode, wakes up periodically to execute core application tasks, and returns to sleep. Additionally, the system must remain responsive to external hardware interrupts while in sleep mode to trigger immediate wake-ups. help me to proceed further.

LP-EM-CC2745R10-Q1: TF-M Secure Image (tfm_s.axf) Fails to Load — CC2745R10-Q1

Zeya Myint — Fri, 14 Aug 2026 00:13:09 GMT

Part Number: LP-EM-CC2745R10-Q1
Other Parts Discussed in Thread: CC2745R10-Q1

Hi,

I’ve been stuck on this following issue for a couple of days and am starting to wonder if it's an unrecoverable hardware problem caused by my earlier tests. Any help would be greatly appreciated!

Thanks,

Zeya

Summary: On a specific LP-EM-CC2745R10-Q1 board, CCS can no longer reliably load tfm_s.axf via a debug session. This worked reliably for weeks of prior testing on this same board and started failing after a single -615 SWD error during unrelated live testing.

Environment: CC2745R10-Q1, LP-EM-CC2745R10-Q1 LaunchPad, SimpleLink Lowpower F3 SDK 9.20.1.21, CCS 2100 (Theia), onboard XDS110 (firmware 3.0.0.43, confirmed current).

Symptom: Loading stock tfm_s.axf intermittently fails with Error -2001: Internal error: Invalid parameter passed to function, GEL trace shows failure at GEL_LoadSecureDebugManager() → "Unable to authenticate with Secure Debug Manager!". Sometimes accompanied by Error -615

TMS3705: TMS3705 and TMS37145 - Communication Error

Vijay Pawar — Thu, 13 Aug 2026 11:36:15 GMT

Part Number: TMS3705
Other Parts Discussed in Thread: TMS37145

Hello,

We are trying to detect the Transponder TMS37145 using the Basestation IC TMS3705FDRQ1.

The Coil used here is having Inductance of 300uH.

After the charge phase, we are able to see the Diagnostic data on SCIO line, but after that we are not able to receive the expected response.
Attached waveforms for reference.
What could be the reason behind this behaviour from Tag, ?
OR

Can you please share, How the SCIO Data looks like for fresh transponder mode, in read only mode.

Also we are trying to keep TXCT line ON for 50ms and OFF for 50ms in continous Loop.
Can you suggest, if this is right way or can you suggest, proper timing diagram.

Regards,

Vijay Pawar

TUSB1211: Vendor specific register access on USB PHY from STM32 ULPI viewport

Alex Fryer — Fri, 07 Aug 2026 07:52:40 GMT

Part Number: TUSB1211
Other Parts Discussed in Thread: TUSB1210

Hi,

I'm attempting to access (read/write) registers on the TUSB1211 USB PHY via the ULPI viewport interface on an STM32. I can successfully read ID registers and write to / read from the scratch register using this interface, but appear unable to access the "extended register space" (addresses > 0x3F), particularly the vendor_specific registers, which I want to access to set eye diagram tuning parameters.

What is the process for accessing the vendor specific registers? Clearly they can't be accessed directly? What is the purpose of register 0x2F, labelled ACCESS_EXT_REG_SET, but with no accompanying documentation in the datasheet?

Thanks,

Alex

SIMPLELINK-LOWPOWER-F3-SDK: Failed to import/generate ECC private key into CC2745R10 HSM

Zeya Myint — Wed, 05 Aug 2026 01:42:56 GMT

Part Number: SIMPLELINK-LOWPOWER-F3-SDK

Hi,

The following report is created by Claude agent from CCS. Please let me know for if you need additional info.

Thanks,

TI_SUPPORT_REPORT.md is fully rewritten and consolidated. Summary of what it now covers:

Crash resolved: doubling crypto_sp's stack (0x1000→0x2000) via a full TF-M rebuild fixed psa_import_key()'s hang/force-reset for both storage backends — confirmed with the exact toolchain/build recipe documented for reproducibility.
Remaining issue unified: both psa_generate_key() and psa_import_key() now consistently return PSA_ERROR_INVALID_ARGUMENT (-135) for identical, spec-correct P-256 ECDSA attributes — traced exhaustively through the shipped source with no rejection point found.
Everything ruled out this session: wildcard vs. concrete algorithm (wildcard reproduces the crash), PSA_KEY_USAGE_EXPORT, key value (fixed known-good vector vs. random), and storage backend (HSM_ASSET_STORE vs LOCAL_STORAGE — identical failure despite sharing almost no code after local_AsymKeyType()).
Dead-end APIs documented: ECDH/ECDSA drivers, direct PKA tokens, raw HSMXXF3 primitives, KeyStore_PSA_importKey() — all
confirmed (via linker map, not just source reading) to funnel into the same compiled validation code.
ITS incident reframed: now explained as NS code calling SIDs that were never wired for external access (ENABLE_ITS_IPC_INTEGRATION is OFF; ITS is locally-integrated into crypto_sp only) — a config/documentation gap, not a mystery.
Three concrete asks for TI, ordered by priority: pinpoint the actual -135 rejection point, confirm/fix the stack-size default, and clarify whether the ITS SIDs should be removed from the manifest or documented as internal-only.

TRF7960: TRF7960 (parallel interface, STM32 host): ISO15693 addressed-mode commands never receive a tag response — non-addressed identical commands work reliably

Durga Devi — Fri, 31 Jul 2026 07:45:28 GMT

Part Number: TRF7960

## Summary

On a custom board (TRF7960RHBT + STM32L4Q5CGTx host, parallel interface), every **non-addressed** ISO15693 command (Read Single Block, Read Multiple Blocks, Write Single Block, Write AFI, Get System Info) works reliably against NXP ICODE SLIX/SLIX2 tags. The exact same commands sent in **addressed mode** (Address_flag set in the Flags byte, 8-byte UID included in the request) never receive any tag response at all — not a CRC error, not a malformed reply, total silence — even with exactly one tag in the field (collision is not possible). This includes the mandatory **Select** command (0x25) and **Stay Quiet** (0x02), both of which fail identically.

We've instrumented the firmware with millisecond-timestamped logging of every chip interrupt, systematically isolated every variable we can control from software (UID correctness, frame length, command type, the Address_flag bit itself), and gone through every low-level parallel-bus function line by line against TI's original reference logic. None of it changes the outcome (details below). At this point the investigation has narrowed to one of two remaining possibilities, and we believe it needs TI's input to go further:

1. A difference introduced by the MSP430 → STM32 parallel interface port, especially in the low-level bus transactions or timing, that isn't visible from a logical code review.
2. A behavior of the original TRF7960RHBT with modern SLIX2 tags that isn't captured in the documentation available to us.

## Hardware

- Reader IC: **TRF7960RHBT**
- Host MCU: **STM32L4Q5CGTx**, parallel 8-bit interface (D0-D7 = PA0-PA7, DATA_CLK = PB6, EN = PB4)
- Host clock: HSI, 16 MHz, no PLL (SYSCLK = HCLK = 16 MHz)
- Firmware base: TI's "6557.TI.Application_Library_1" reference code, ported from the original MSP430 target to this STM32L4 (parallel bus bit-banging, ISR structure, and `HostRequestCommand()` largely unchanged in logic from the original reference)
- ISO_CONTROL register confirmed as `0x00` throughout testing → ISO15693, **low data rate, 1-out-of-4 coding** (VCD-to-VICC)
- Tags: NXP ICODE SLIX / SLIX2 (UID prefixes consistent with that family)
- Antenna: single loop antenna via U.FL/SMA, one tag present for all tests below (no anti-collision scenario)

## What works

Inventory (its own separate slot-based addressing, not Address_flag) finds tags reliably. All **non-addressed** Read/Write/Get-System-Info commands succeed reliably, single tag or multiple.

## What fails

Any command with Address_flag set (Flags byte `0x20`) plus the target's 8-byte UID:
- Select (`0x25`)
- Read Single Block (`0x20`) addressed
- Stay Quiet (`0x02`, always addressed per spec)
- Get System Info (`0x2B`) addressed — mandatory command, no memory access, no block-number parameter

All produce **zero tag response**, every time, single tag, no collision possible.

## The strongest evidence: content- and command-independence

We ran three targeted experiments specifically to find out whether the tag's silence has anything to do with what's actually in the addressed frame, or whether it's independent of content and command type entirely.

**UID corruption test.** Sent Select to the same tag four times back to back: once with its real UID, then three more times with a single bit flipped in the first, a middle, and the last UID byte respectively.

```
Correct UID: <A0@2607><80@2609>{TXi00j02@260A}{RETRY}{RXi00j01@2657}[]
First byte flipped: <A0@268F><80@2690>{TXi00j02@2692}{RETRY}{RXi00j01@26DF}[]
Middle byte flipped: <A0@2717><80@2718>{TXi00j02@271A}{RETRY}{RXi00j01@2767}[]
Last byte flipped: <A0@279F><80@27A0>{TXi00j02@27A2}{RETRY}{RXi00j01@27EF}[]
```

All four are byte-for-byte identical in IRQ sequence, iteration counts, and timing (within normal jitter). If the tag were receiving and evaluating the UID field at all — even just to silently reject a mismatch — we'd expect some distinguishable difference between "correct UID" and "wrong UID." Getting the identical result regardless of UID content means the tag isn't getting far enough to compare it.

**Forced Address_flag test.** To separate the Address_flag bit from frame length (every addressed failure above was also a longer 10-11 byte frame, confounding the two), we sent a deliberately invalid 3-byte frame: `20 20 01` — Address_flag set, but no UID at all, the same length as a proven-working non-addressed frame.

```
20 20 01 (Address_flag set, no UID, 3 bytes): <80@19D8>{TXi00j01@19DA}{RETRY}{RXi00j01@1A27}[]
```

No `0xA0` interrupt this time (that interrupt — "TX active, FIFO nearing empty" — turns out to be purely a function of frame length approaching the chip's 12-byte FIFO capacity, appearing on every 10-11 byte addressed frame and never on any 3-byte frame, addressed or not). This isolates that setting the Address_flag bit alone, independent of length, doesn't change the chip's own TX-side interrupt behavior. (No response was expected either way here since this is an invalid frame per spec — the value of this test is purely the absence of `0xA0`, not the lack of a reply.)

**Addressed Get System Info test.** To separate "command touches tag memory" from "command is addressed," we sent Get System Info (`0x2B`) addressed — a mandatory command for every compliant tag, no memory access, and critically no block-number parameter at all (10 bytes: flags + cmd + UID only).

```
20 2B [UID] (addressed Get System Info): <A0@9909><80@990B>{TXi00j02@990C}{RETRY}{RXi00j01@9959}[]
```

Identical signature to Select and addressed Read Single Block, reproduced twice. This rules out "something specific to memory-access commands" — a command that touches nothing and takes no extra parameters fails exactly the same way.

**Taken together:** correct UID, wrong UID (any byte position), no UID at all with just the flag bit set, and a mandatory parameter-free command, all produce the same outcome. The tag's behavior toward anything with Address_flag set is indistinguishable regardless of content or command type — which is about as conclusive as software-side testing can get that this isn't a content/logic problem on the tag side.

## Side-by-side evidence (same tag, same session, moments apart)

This log line captures an internal non-addressed Get System Info call (used as a priming step) immediately followed by the actual addressed Read Single Block request to the same tag:

```
TX: 011200030420148937950108070001000000
RX: 011200030420148937950108070001000000 ISO 15693 Read Single Block request.
<80@1AE0>{TXi00j01@1AE2}{RETRY}<60@1AEF><40@1AF7>{RXiFFj00@1B21}[000F148937950108E000074F03]
{TX<A0@1B59>i00j01@1B5A}<80@1B5B>{RETRY}{RXi00j00@1B9A}[]
```

Reading the two exchanges in this line:
1. **Non-addressed (succeeds):** IRQ_STATUS `0x80` (TX complete) → retry/reset step fires → `0x60` (RX active, FIFO draining) → `0x40` (RX EOF, success) → real data `[000F148937950108E000074F03]` returned.
2. **Addressed, same tag, immediately after (fails):** IRQ_STATUS `0xA0` → `0x80` (TX complete) → retry/reset step fires → **no further IRQ event of any kind** for the remainder of the RX-wait window → software timeout forces "no response."

## What we've ruled out

1. **RX response-wait timeout too short** — extended `RX_NO_RESPONSE_WAIT_TIME` to the register's documented maximum (~9.6 ms). No change.
2. **Multi-tag collision** — reproduced with exactly one tag in the field. No change; identical failure.
3. **`HostRequestCommand()`'s FIFO chunking/refill loop** — traced the arithmetic by hand: for both the 3-byte non-addressed and 10-11 byte addressed frames, `rxtx_state` goes negative after the initial burst, meaning neither needs the multi-chunk refill path; both transmit in a single burst. Confirmed identical behavior for both lengths.
4. **Reset-and-retransmit gate condition** (the `{RETRY}` step above, calling `Trf796xReset()` + Direct Command `TRANSMIT_NEXT_SLOT`) — confirmed via code trace and the timestamped log above that it fires identically, every time, for both addressed and non-addressed commands. Not a differentiator.
5. **Parallel bus (MCU-to-chip) signal timing** — the original reference `ParallelRawWrite()` toggles the DATA_CLK line with zero delay (`CLK_ON` immediately followed by `CLK_OFF`, back-to-back instructions, inherited unchanged from the original MSP430 code). Added an explicit ~625 ns settle delay around every clock edge and byte transition (setup/pulse-width/hold) as an experiment. Rebuilt, reflashed, retested: **byte-for-byte identical failure**, no change whatsoever.
6. **Explicit ISO15693 Select before the addressed read** — implemented Select (`0x25`) as its own command and tested issuing it immediately before the addressed Read Single Block, in case the tag needed to be moved into "Selected" state first. Select itself gets the identical no-response result.
7. **Oscilloscope check (near-field probe on the antenna feed)** — confirms the reader transmits a real ~13.56 MHz carrier of comparable amplitude and duration in both addressed and non-addressed cases (rules out "no transmission at all"). Bit-level content comparison from phone-photo captures was inconclusive at the resolution available to us.
8. **UID content, Address_flag, and command-type isolation** (see above) — correct UID, corrupted UID (3 byte positions tested individually), no UID at all with just the flag bit set, and a mandatory parameter-free command (Get System Info) with no memory access, all produce identical results.
9. **Direct register readback** — attempted to verify `TX_LENGTH_BYTE_1`/`TX_LENGTH_BYTE_2` (`0x1D`/`0x1E`) and the FIFO (`0x1F`) contents directly via standalone write-then-read-back operations. Both consistently read back as empty/zero regardless of what was written, **including for transmissions we know succeed** — so we don't believe this reflects a real fault, but rather that these registers may not support readback via this out-of-band access pattern (outside the normal unbroken continuous-write-into-FIFO burst). We could not get a reliable readback method working from our side. If there's a supported way to verify TX length/FIFO content on this chip via the parallel interface, we'd welcome guidance.
10. **Full cycle-by-cycle review of every parallel-bus function against TI's original MSP430 reference logic** — went through `ParallelReadSingle`, `ParallelReadCont`, `ParallelWriteSingle`, `ParallelWriteCont`, `ParallelRawWrite`, and the `ParallelStartCondition`/`ParallelStopCondition`/`ParallelStopContinuous` helpers line by line. Addressing bit-patterns (single vs. continuous, read vs. write), direction switching, and start/stop sequencing all correctly match TI's documented conventions — no logic errors found. The `Start`/`Stop` condition helpers had never received the settle-delay treatment applied to the four main transfer functions (item 5); added it for completeness and retested. No change — expected, since these helpers run once per transaction and are used identically by both the working non-addressed and failing addressed paths, so a defect there should affect both equally rather than differentiating by length. This closes out the parallel-interface code as a source of the length-correlated failure as thoroughly as we're able to from software alone.
11. **`SPECIAL_FUNCTION` (`0x10h`) `BIT1` ("14_anticoll")** — TI's own app note SLOA156 ("Comparison of TRF7960 and TRF7960A") documents that the TRF7960 (non-A) can't process ISO14443A Layer-4 frames whose first byte matches an anti-collision SEL code (`0x93`/`0x95`/`0x97`), fixed on the TRF7960A by this bit (disables anti-collision framing interpretation after anti-collision completes). We tested it anyway even though our commands are ISO15693, not ISO14443A (our Flags byte, `0x20`, doesn't match those SEL codes, and this bit is never touched anywhere in our own ISO15693 code path): set `BIT1`, immediately attempted addressed Select, restored the bit. **No change** — identical failure signature, reproduced twice. Rules out this specific bit as directly relevant, but see below — we think the *existence* of this erratum is still meaningful context.
12. **`DATA_CLK` rate recalibrated against the datasheet's own numbers** — Section 6.7 (Figures 6-6/6-7/6-8) labels the Start Condition's minimum pulse at 50 ns, and the electrical characteristics table gives `DATA_CLK`'s recommended maximum as 2 MHz (absolute max 8 MHz), explicitly noted as depending on capacitive load on the I/O lines. Our unmodified port's natural (zero-delay) per-byte clocking rate works out to roughly 1.3-2.7 MHz at 16 MHz HSI — in the neighborhood of, or slightly above, the recommended 2 MHz. We recalibrated the settle-delay margin (item 5) to deliberately target ~1 MHz (half the recommended maximum, comfortably clear regardless of this board's actual capacitive loading) rather than an arbitrary NOP count, rebuilt, reflashed, and reran every diagnostic in this document. **Every single one reproduced its exact prior failure signature, byte for byte** — no change whatsoever. This is the strongest timing-side negative result we have: a deliberately calculated, spec-derived, conservative clock rate made no difference at all.

## Firmware construction detail (for reference)

`HostRequestCommand()` builds the TRF7960 command header as:
```
pbuf[0] = 0x8F // Direct Command: reset FIFO
pbuf[1] = 0x90/0x91 // Direct Command: transmit without/with CRC
pbuf[2] = 0x3D // continuous address write starting at register 0x1D
pbuf[3] = length >> 4 // TX Length Byte 1
pbuf[4] = (length << 4) | broken_bits // TX Length Byte 2 + broken-bits count
```
followed immediately by the actual ISO15693 frame bytes (Flags, Command, optional UID, optional data), all written in one continuous burst via the parallel bus. `length` correctly reflects the ISO15693 frame's own byte count (3 for non-addressed Read Single Block, 10-11 for addressed) — verified this is computed identically and correctly for both cases.

Example addressed Read Single Block frame (11 bytes, before the chip auto-appends CRC16): `20 20 [UID × 8 bytes] [block]`.

## Why we think this needs TI specifically: SLOA156 precedent

Your own app note SLOA156 ("Comparison of TRF7960 and TRF7960A") documents that the original TRF7960 has at least one confirmed silicon-level limitation in exactly this *shape* — addressed/framed command processing failing depending on the first byte of the frame, undocumented in the main datasheet, and fixed only in the TRF7960A via a register bit (`SPECIAL_FUNCTION` `BIT1`, "14_anticoll") rather than a firmware workaround. That specific fix is scoped to ISO14443A (anti-collision SEL codes `0x93`/`0x95`/`0x97`), and we've confirmed it doesn't apply to our ISO15693 case (tested directly — see ruled-out item 11). But its existence tells us this general category of problem — an addressed/framed command silently failing on the TRF7960 due to something not captured in the main datasheet, only surfaced in a chip-comparison document — is a real, precedented thing for this chip, not a hypothetical. That's why we think TI's own internal knowledge of the TRF7960 vs. TRF7960A differences is the most likely place left to find an answer, rather than anything further we can test from our side.

## Questions for TI

1. Is there a known erratum or documented behavior specific to **addressed** (Address_flag-set) ISO15693 requests on the TRF7960/TRF7960A, particularly for frame lengths in the 10-12 byte range that approach the chip's 12-byte FIFO capacity?
2. Given that non-addressed commands succeed reliably and addressed commands produce total silence — and that this silence is completely independent of UID content, frame length, and command type (see the isolation tests above) — what would you recommend checking next: specific registers, a different Direct Command sequence, or an RF-level verification technique?
3. Is the `TRANSMIT_NEXT_SLOT` Direct Command (used here in the post-TX "retry" step, per the original reference code) appropriate for non-inventory addressed commands, or could its use here be masking/altering the transmit sequence in a way that isn't visible from the interrupt trace we can capture?
4. Is there a supported way to read back `TX_LENGTH_BYTE_1`/`TX_LENGTH_BYTE_2` or FIFO contents outside of an active transmission, to directly verify what the chip actually latched? Our own attempts at this were inconclusive (see ruled-out item 9).
5. Are there known antenna-matching, transmit-power, or modulation-index considerations specific to **longer** ISO15693 VCD-to-VICC transmissions that could explain a tag correctly and silently ignoring a frame that software reports as sent correctly and that is content-independent in its failure mode?
6. Per SLOA156's precedent (see above): is there an analogous, undocumented ISO15693 addressed-mode limitation on the TRF7960 (non-A) that the TRF7960A also happens to resolve — even if not written up as explicitly as the ISO14443A case?

TPS43061: Parts 90 out in tape and reel

Lamond Bauman — Wed, 29 Jul 2026 18:00:20 GMT

Part Number: TPS43061

I am trying to figure out what is the probability that parts in the middle of a reel can be 90 degrees out from the rest of the reel.

LSF0102: Request for MSL Verification and Supporting Objective Evidence – LSF0102QDCURQ1, Lot 6026005HFT

Melissa Sheats — Tue, 28 Jul 2026 21:32:59 GMT

Part Number: LSF0102

Hello,

I am requesting assistance in verifying the moisture sensitivity level (MSL) for the following material:

Part Number: LSF0102QDCURQ1
Lot Number: 6026005HFT
Date Code: 2610
Assembly Site: HFT
Bag Seal Date: 03/15/2026

The TI manufacturer packaging label for this lot identifies the material as:

MSL 1 / 260C / Unlimited Floor Life

However, our customer, has reviewed the current TI datasheet/product information and believes the part should be classified as MSL 2.

Additionally, we have identified TI information indicating that the MSL classification for LSF0102QDCURQ1 may vary depending on the manufacturing/assembly site. Due to the conflicting information between the lot-specific packaging label and the customer's interpretation of the datasheet, we are seeking clarification directly from Texas Instruments.

Could you please:

Confirm the correct moisture sensitivity level for Lot 6026005HFT.
Confirm the MSL classification associated with Assembly Site HFT.
Provide objective evidence supporting the applicable MSL classification for this lot, such as a manufacturing site qualification record, MSL lookup results, package qualification documentation, or other supporting TI records.
Confirm whether the MSL 1 designation shown on the manufacturer label is correct for this specific lot.

We would appreciate any documentation that can be shared to support our response to the customer and close this discrepancy.

Thank you for your assistance.

RI-STU-MRD2: Availability or Replacement for Legacy RFID Reader RI-STU-251B

lucas ebbo — Tue, 21 Jul 2026 09:22:39 GMT

Part Number: RI-STU-MRD2

Hello,

We are currently using a Texas Instruments RFID reader in our production equipment and need to purchase a replacement unit.

Product details:

- Series 2000 Reader System

- Reader S251B

- Part Number: RI-STU-251B

- Internal module references visible on the hardware:

- RI-STU-251B-30

- RI-RFMI-0078-30

The product appears to be obsolete and is no longer listed in the TI support portal.

Could you please advise:

1. Whether this reader or any compatible spare units are still available for purchase.

2. If not, what is the current Texas Instruments equivalent or recommended replacement.

3. Whether the recommended replacement is compatible with existing Series 2000 RFID transponders and installation.

Photos of the equipment are attached for reference.

Thank you for your assistance.

Best regards,

Lucas EBBO

Rousset SAS

France

CC2652R: Guidance Required for Passive Keyless Entry Key Fob Development

Ramkumar Ramasamy — Tue, 21 Jul 2026 01:59:38 GMT

Part Number: CC2652R
Other Parts Discussed in Thread: CC2745R10-Q1, UNIFLASH

Hi Team,

Good day..!

I am planning to develop a proof-of-concept Passive Keyless Entry (PKE) system and would appreciate your guidance in selecting the appropriate solution and understanding the overall system architecture.

Specifically, I would like to understand the following:
1. How does a Passive Keyless Entry (PKE) system work from key detection to authentication and unlocking?
2. Could you provide design guidelines for the antennas, including recommended PCB layout practices, matching networks, tuning methods, and reference antenna designs?
3. Is an external MCU required, or are there integrated solutions that include both the MCU and RF functionality?
4. What are the essential hardware components required on:
* the key fob (transmitter)
* the vehicle side (receiver/base station)
5. Which communication technologies are typically used?
6. What factors primarily influence the operating distance (antenna design, transmit power, receiver sensitivity, matching, enclosure, battery voltage, environmental conditions, etc.)?
7. Could you recommend suitable low-cost ICs for both the key fob and vehicle side, along with their datasheets, application notes, evaluation boards, and reference designs?
8. Are there complete reference designs, firmware examples, or software development kits (SDKs) available to accelerate development?
My goal is to understand the complete hardware architecture and select the appropriate components before beginning the design.
I would appreciate any recommended documentation, application notes, reference designs, or evaluation kits that would help me get started.
Thank you for your support.
Best regards,
Ram

TRF7970A: Linux software library for TRF7970A to interface with a MIfare DesFire Ev3 RFID tag.

anh tuan hoang — Thu, 16 Jul 2026 23:09:46 GMT

Part Number: TRF7970A

We were wondering if TI can propose a software stack (C or C++) that can take advantage of the security feature of EV3? Like anti card cloning, encryption and SDM.

@anjli@ti.com @sworkman@ti.com

RF430CL330H: What is the difference between part number RF432S72FDMWRGZRQ1 and RF432S72FDKWRGZRQ1

Eddie Gonzalez — Tue, 14 Jul 2026 16:07:38 GMT

Part Number: RF430CL330H

Hello,

Can you please tell me what the difference between PN: RF432S72FDMWRGZRQ1 vs RF432S72FDKWRGZRQ1 is?

Thank you.

RI-TRP-DR2B: 3D Cad Data Request of RI-TRP-DR2B-40

kubra Aksu — Mon, 13 Jul 2026 12:16:39 GMT

Part Number: RI-TRP-DR2B

Hello

We need 3D Cad Data of RI-TRP-DR2B-40 with in step format. Could you please share with me by e-mail? If you need that i had a offer for the product i can share it.

CC2591: 2.2 Ghz peak observed in EMI testing

Akhil Aithal — Tue, 07 Jul 2026 07:56:33 GMT

Part Number: CC2591
Other Parts Discussed in Thread: CC2520

Hello,

we are using a CC2520 zigbee transmitter in combination with a CC2591 range extender for our product. While carrying out the EMI testing, we find that there exists a 2.2GHz peak along with our intended 2.4GHz signal. The magnitude of the signal is comparable to the 2.4GHz signal. We are using a test software to transmit every 10-100ms and we are able to set the channel and transmit power. What we observe is that the channel and transmit power of our target signal at 2.4GHz is behaving as per our setting, but the unintended signal at 2.2GHz remains unchanged in its frequency as well as power for any setting.
I am looking to find the root cause and potential solutions for this. It would be very helpful if you could support.

Thank you.

Regards,

Akhil

CC2340R5: openocd and cc2340r5 launchpad

Andy Rutter — Fri, 03 Jul 2026 21:56:40 GMT

Part Number: CC2340R5

Which openocd board .cfg file should I use for the cc2340r5 launchpad development board?

-- Andy

CC2662RQ1-BCU-EVM: Available to Purchase

Caitlyn Cavanagh — Tue, 30 Jun 2026 19:38:25 GMT

Part Number: CC2662RQ1-BCU-EVM

Hello, is the CC2662RQ1-BCU-EVM available to purchase? If not, can you recommend a similar product that is available?

TRF7970A: RX pin voltage level issue

user5883945 — Mon, 29 Jun 2026 14:10:12 GMT

Part Number: TRF7970A

Dears,

The datasheet describes that in direct mode 0, when the RX pin does not emit waves, it is at a low level. However, when I tested that it does not emit waves, the RX pin is at a high level. Is there any difference between the two?

CC8520: Input Voltage Clarification

Alex Segler — Fri, 26 Jun 2026 14:11:58 GMT

Part Number: CC8520

Hello team - can you tell me if there is a configuration of CC8520 within your recommendations that is compatible with 1.8V logic? We are trying to avoid a level shifter and the datasheet does not provide logic voltage thresholds. Assuming V(high)=0.7Vcc, I think it would be valid to run CC8520 at Vcc=2.0V and that should allow it to be compatible with logic levels.

Thanks!

LP-EM-CC2745R10-Q1: Release-to-Market Date

TI-CSC — Wed, 17 Jun 2026 11:58:46 GMT

Part Number: LP-EM-CC2745R10-Q1

Hello E2E Experts,

When will the multiple antenna booster pack (as shown in the video), be released to mass-market?

www.ti.com/.../6366746223112

Regards,

TICSC

CC2500: Specific Tools for RF Design

Atilano Valadez — Mon, 15 Jun 2026 15:12:07 GMT

Part Number: CC2500
Other Parts Discussed in Thread: CC2340R5, CC2340R2

1.- Could you please specify the mandatory components that need to be purchased to implement the attached design using the CC2500 , PIC18F46K42 and ATECC608B?

2.- How many each?

CC2500: Firmware Example Using CC2500

Atilano Valadez — Fri, 12 Jun 2026 16:50:55 GMT

Part Number: CC2500

Could you please provide a firmware example demonstrating how to use the CC2500 transceiver?

TMS3705: TMS3705 ISO 11785 HDX Tag Reading Failure – Abnormal Waveforms at SENSE and SFB Pins

Derek Wu — Thu, 11 Jun 2026 06:34:48 GMT

Part Number: TMS3705
Other Parts Discussed in Thread: UCC27524

Dear TI Experts,
I am using the TMS3705 for reading ISO 11785 HDX tags. The schematic is based on the standard TMS3705 HDX reference design, but the reader is not able to successfully read tags.
The 134.2 kHz carrier for the antenna is generated by another chip, so the TMS3705’s own antenna driver is not used. The UCC27524’s UCC_EN pin is used to enable/disable the carrier output.
Below is the current situation (waveform names correspond to the test points; e.g., 1_RX_ANT_3.png shows the waveform at net RX_ANT_3, and so on):

Waveform 1_RX_ANT_3.png: Although there is some sawtooth distortion, the 134.2 kHz signal looks reasonably standard.
Waveform 2_BAV99,215.png: After passing through the BAV99,215 limiter, the signal is still 134.2 kHz.
Waveform 3_R36_C60.png: After the AC coupling capacitor C60, the negative portion of the waveform disappears (as expected).
Waveform 5_SENSE.png: At the SENSE pin (after resistor R36), the waveform becomes abnormal.
Waveform 6_SFB.png: The waveform at the SFB pin is also clearly distorted.

My questions are:

What is causing the distortion of the waveforms at the SENSE and SFB pins?
How should I modify the circuit to fix this?

Thank you very much for your help!

CC2340R2: REQUEST FOR IBIS MODEL

ramakrishna Sanga — Thu, 11 Jun 2026 06:25:33 GMT

Part Number: CC2340R2

Dear TEXAS INSTRUMENT Team,

I hope this message finds you well.

I Want CC2340R21N0RGER this IC's IBIS Model. Could you please Share Them.

Thank you for your time and support. I look forward to your response.

Best regards,
Argus Embedded Systems.

RF-HDT-DVBB: Availability of stock

Dean Carter — Wed, 10 Jun 2026 06:25:59 GMT

Part Number: RF-HDT-DVBB

Hi,

I am needing 10000 units of the RF-HDT-DVBB-N2, can I please have the availability for the RF-HDT-DVBB-N2, if they are not in stock when would they be next available?

Regards

Dean Carter

TRF7970A: Operating Temperatures of RFID IC's with NFC

Rashad Rolle — Tue, 09 Jun 2026 15:56:50 GMT

Part Number: TRF7970A

I am currently searching for an NFC chip with an operating temperature between 150 - 204 degrees Celcius. Would you happen to have anything available?