Other wireless technologies forum - Recent Threads

TPS25981: Please provide TPS25981 certificate report.

Huang Hanaco — Mon, 05 Oct 2026 03:17:23 GMT

Part Number: TPS25981

We are using the TPS25981 component in our product that will require UL certification in the future. According to the datasheet, the component has obtained an IEC 62368-1 CB certificate, but I can't fine the certificate on TI website. Could you please assist us in providing this document? Thank you.

CC2340R2: OOK 10kBit/s possible on CC2340R2

Kilian Timmler — Mon, 28 Sep 2026 09:59:20 GMT

Part Number: CC2340R2
Other Parts Discussed in Thread: CC2500, CC2550, , CC2652R

Hi,

I'm just pondering on what part of either CC2500 or CC2550 to use as simple wake up transmitter at 2.4GHz. The product page suggests a CC2340R2 as replacement part but with SmartRF Studio it appears impossible to configure it for OOK at 10kBit/s. Do any of the newer parts support OOK at all? Is there maybe an example application out there?

I hope you can help.

Best Regards,

Kilian

CC2642R-Q1: CC2642R-Q1 Radio test

xuanfeng fu — Mon, 28 Sep 2026 02:04:46 GMT

Part Number: CC2642R-Q1

Hello

Our project utilizes the CC2642R-Q1 and requires testing of RF indicators. Could you please inform me if there are any relevant documents and tools available? Thank you!

TPS546D24A: Material composition information and exemption

UDAY MS — Wed, 23 Sep 2026 12:04:26 GMT

Part Number: TPS546D24A

Hello team,

Thank you for providing the material content information for part number TPS546D24ARVFR.

Upon reviewing the data, I noticed that the Clip Adhesive and Die Attach Adhesive sections indicate the presence of lead. Could you please clarify why lead is present in these materials and provide additional details regarding its application?

Additionally, I observed that the RoHS exemption 7(a) has been claimed. Could you please explain the basis for applying this exemption to the reported lead content?

Thank you for your support. I look forward to your clarification.

TPS62130: DISCREPANT MATERIAL REPORT NCMR 13040 LFGB101-01129 / TPS62130RGTR / TEXAS INSTRUMENTS INCORPORATED..

Axel Antonio Loaeza Kim — Fri, 18 Sep 2026 00:22:38 GMT

Part Number: TPS62130

QCER NCMR 13040 LFGB101-01129 _ TPS62130RGTR TEXAS INSTRUMENTS INCORPORATED.. - Template (1).pdf

MSPM0G1107: MSPM0G1107TRGZR change to Tray packing

Peter Liang — Wed, 16 Sep 2026 06:14:15 GMT

Part Number: MSPM0G1107

MSPM0G1107TRGZR is T&R packing, project team would like to change to Tray packing.

Please help check if have Tray packing, then provide the price and MPN, thanks.

TRF7970A: Unable to detect the UID of the tag.

Shubham Singh — Wed, 16 Sep 2026 06:01:07 GMT

Part Number: TRF7970A
Other Parts Discussed in Thread: DLP-7970ABP

Hi TI Team,

Currently, we are working on the bring-up of the TRF7970A RFID module using the SAM9X75-Curiosity Evaluation Kit.

For this setup, we are using the DLP-based TRF7970A module. I have attached an image of the module for your reference

We have completed the required pin multiplexing and device-tree configuration for interfacing the TRF7970A module over the SPI interface using our Yocto build.

The relevant device-tree node and pin-multiplexing configuration are attached below for your reference:

After building the Yocto image and flashing it onto the SAM9X75-Curiosity board, we verified that the TRF7970A driver is loading successfully and the device is binding correctly to the SPI interface.

The corresponding logs are attached below:

However, when using the NFC tool for polling and tag detection, the RFID tag is not being detected, even though the driver is loaded and the module is successfully bound.

The polling output is attached below:

Could you please help us debug this issue and suggest the appropriate steps or checks to identify why the TRF7970A is unable to detect the RFID tag?

In particular, it would be helpful if you could advise us on any additional SPI configuration, GPIO/IRQ configuration, TRF7970A register settings, power/reset sequencing, or NFC tool configuration that we should verify.

Please let us know if you need any additional logs, register dumps, device-tree details, or hardware information from our side.

LMR51603: Is any ROM writing/programming required for this IC

?? ?? — Tue, 15 Sep 2026 04:05:06 GMT

Part Number: LMR51603

Dear PIC

This item is IC.

Is any ROM writing/programming required for this IC?

LMR51603XQDBVRQ1

RF430F5978: RF430F5155DWRGZQ1, inquiry for the device datasheet and programming specification

Frantisek Zabecky — Mon, 14 Sep 2026 10:47:49 GMT

Part Number: RF430F5978

Hello,

I would like to ask you send me the device datasheet of RF430F5155DWRGZQ1 and also the programmign speciofication for this device.

We've received request to implement the programming support of RF430F5155DWRGZQ1 for our programming tools (device programmers).

Thank you in advance.

Best regards,

Frantisek

CC2652RSIP: device o/p filter

Mahalakshmi Iyadurai — Sat, 12 Sep 2026 15:34:52 GMT

Part Number: CC2652RSIP

We have planned to use a bandpass filter at cc2652rsip o/p to reduce harmonics and then connect a 1 watt amplifier. whether the 15 pf mentioned at the o/p of sample circuit can be removed and in place of that capacitor whether we can use a band pass filter 2450BP07A0100. whether the 15 pf capacitor is mandatory for this device.

if 15 pf is to be connected at the o/p, if we have planned to remove the low pass filter, whether we can place a 0 ohm resister without disturbing the o/p level of the cc2652rsip.

thank you.

AM3352: AM3352BZCZD80 core board has an intermittent boot failure issue.

ELFIN JIANG — Fri, 11 Sep 2026 09:13:15 GMT

Part Number: AM3352

Hi Team,

We found the core board with AM3352BZCZD80 has an intermittent boot failure during operation. Repeated power on/off stress tests show various issues including system hang-up and application startup failure. The issue is intermittent and reproducible.

RI-TRP-DR2B: Compatibility of RI-TRP-WR2B Product

HYUNJU LEE — Fri, 11 Sep 2026 05:11:33 GMT

Part Number: RI-TRP-DR2B

Hello,

I am looking for a replacement for a discontinued product.

Could you please confirm whether the RI-TRP-WR2B has the same compatibility as other R/W transponders, such as the RI-TRP-W9TD and RI-TRP-W9UR?

Specifically, does the RF data frame format of the “32-mm Glass Transponder Read Only, Read/Write” described in SCBU019.pdf remain the same across these products?

We would appreciate your official confirmation regarding the compatibility and RF data frame format.

Thank you for your assistance.

Best regards,

CC2755P20: CC2755P207E0WRHAR programming specifications

GURUKUMAR YADAV BAIRAGANI — Tue, 08 Sep 2026 08:53:27 GMT

Part Number: CC2755P20
Other Parts Discussed in Thread: UNIFLASH

Hi Team,

can you please provide us the programming sepcification for HSM range for CC2755P20 device and provide inputs on how to program the hsm range.

Thanks!

Gurukumar B

TMS3705: TMS3705 IEC 61000-4-6 Immunity Issue - PCB Layout Recommendation

Ryu Yamashita — Mon, 07 Sep 2026 05:28:45 GMT

Part Number: TMS3705

Hello Team,

We are using the TMS3705 and encountered communication failures during IEC 61000-4-6 conducted immunity testing.

After adding a common-mode choke (BNX028-01) to the antenna communication path, immunity performance improved significantly. Based on this result, we suspect that conducted RF noise is coupling into the ANT1/ANT2 signal path.

We have attached the schematic, PCB layout, and test results.

EMC_Translation.pdf

Could you please review the design and advise:

Recommended PCB layout improvements for ANT1/ANT2 routing
Component placement recommendations around the TMS3705
Additional filtering or EMC countermeasures that TI recommends

Any feedback would be greatly appreciated.

Best regards,
Ryu.

CC2755P20: CC2755P207E0WRHAR PIN MAPPING

GURUKUMAR YADAV BAIRAGANI — Fri, 04 Sep 2026 07:40:40 GMT

Part Number: CC2755P20
Other Parts Discussed in Thread: UNIFLASH, SYSCONFIG

Hi Team,does pin 25 is required to program the device using swd protocol ? Please confirm.

Thanks!

CC2755P20: DEVICE MARKINGS ISSUE

GURUKUMAR YADAV BAIRAGANI — Wed, 26 Aug 2026 09:49:09 GMT

Part Number: CC2755P20

Hi Team,can I use this device to program CC2755P207E0WRHAR this,I see marking is P10 and my device is P20 so does it possibleto use or we need to get P20 samples for testing ? Please provide clear explination on this.

Thanks!

CC3220S-LAUNCHXL: CC3220S-LAUNCHXL: CC3220S SL_AF_RF / SL_SOCK_RAW: millisecond RX indication latency under busy RF conditions

Ashot Andrieiev — Wed, 26 Aug 2026 08:49:09 GMT

Part Number: CC3220S-LAUNCHXL
Other Parts Discussed in Thread: CC3220S,

Hello,

We are evaluating the CC3220S transceiver mode for a deterministic point-to-point radio link and have observed an RX latency behavior that we would like to understand better.

Environment

CC3220S-LAUNCHXL, two boards
SimpleLink CC32xx SDK 7.10.00.13
Host Driver 3.0.1.71
NWP 3.22.0.1
TI-RTOS7
TI Arm Clang 2.1.2 LTS
SL_AF_RF
SL_SOCK_RAW
2.4 GHz fixed channel
11 Mbps
short preamble
fixed 816-byte raw packets
ACK disabled
one frame per sl_Send()
application/NWP power-save policies disabled for the test

The transmitter sends fixed packets periodically. A GPIO is asserted immediately before sl_Send().

On the receiver we instrumented three timing points with a logic analyzer:

TX application GPIO immediately before sl_Send()
RX CC3220 NWP host IRQ entry
RX application GPIO immediately after the target packet returns from sl_Recv()

We instrumented the NWP IRQ by wrapping the existing _SlDrvRxIrqHandler() using the already-created g_intHandle; the original handler is still called from the wrapper.

The important observation is that:

NWP host IRQ → sl_Recv() return is very stable.

Typical measurements:

median ≈ 0.60–0.61 ms
p99 variation around the median ≈ 10 µs
maximum variation only tens of microseconds

However:

TX sl_Send() entry → RX NWP host IRQ can have large positive latency excursions.

On a quiet RF channel we typically see:

nominal TX → RX NWP IRQ ≈ 2.41 ms
p95 additional latency: tens of microseconds
p99 additional latency: tens to low hundreds of microseconds

On a busy 2.4 GHz channel, with the same firmware and packet geometry, we have observed:

p95/p99 additional latency in the millisecond range
individual positive excursions of approximately +3 ms or more

The nominal latency remains almost unchanged; the difference is mainly occasional positive tails.

We have already tested the following possible causes:

disabling the CC32XX Power policy: no material effect
increasing the application task priority: no material effect
increasing the SimpleLink spawn task priority: no material effect
changing TX packet cadence from 10 to 40 ms: millisecond tails still occur
the TX-side sl_Send() execution time itself is very stable
RX host processing after the NWP interrupt is very stable

We also used sl_DeviceStatStart/Get/Stop().

When the RF channel was quiet, RX statistics were approximately only our own packets and timing was very good.

During earlier busy-channel tests we observed thousands of foreign valid packets and much larger timing tails.

We then generated controlled foreign valid raw frames ourselves and used an explicit transceiver RX filter with:

SL_WLAN_RX_FILTER_HFIELD_L1_PAYLOAD_PATTERN
pattern "FX01"
transceiver role
DROP action
explicit SL_WLAN_RX_FILTER_STATE enable and state readback

The filter was confirmed enabled and successfully prevented the synthetic foreign frames from reaching the host. ReceivedValidPacketsNumber still counted those filtered frames, as expected.

However, a moderate deterministic stream of valid foreign frames by itself did not reproduce the large millisecond tails seen on a naturally busy RF channel.

Our understanding from the documentation is that SL_SOCK_RAW operates with CCA override, so normal 802.11 CSMA/CCA backoff should not explain this behavior.

We would therefore appreciate clarification on the NWP behavior in transceiver mode:

Can reception of other RF activity — including valid foreign WLAN frames, corrupted frames, FCS-error frames, overlapping transmissions, or other PHY events — delay the NWP host interrupt associated with an otherwise successfully received SL_SOCK_RAW packet?
Is there an internal RX queue/buffer in the NWP for transceiver mode? If so, what is its depth and scheduling behavior?
Is there any documented or characterized worst-case latency from successful PHY reception of a raw packet to assertion of the NWP host interrupt?
At what point in the RX processing path is SlTransceiverRxOverHead_t.Timestamp captured? Is it associated with PHY packet start, PHY packet completion, MAC processing completion, or another internal event?
Can FCS-error or otherwise rejected PHY receptions consume internal NWP processing time even though those packets are never returned by sl_Recv()?
Does SL_SOCK_RAW completely bypass CCA/backoff for each transmitted packet, or are there any other RF/MAC conditions inside the NWP that can postpone actual transmission despite using RAW transceiver mode?
Are there known limitations of CC3220S/CC323x transceiver mode regarding deterministic packet timing or bounded RX indication latency?

Our main design question is not maximum throughput. We need to determine whether the public CC3220 transceiver API can provide a bounded receive timing window for a fixed-length, fixed-rate, deterministic TDD link.

If useful, we can provide logic-analyzer captures, UART logs, and a minimal reproducer.

Thank you.

CC2755P20: CC2755P207E0WRHAR

GURUKUMAR YADAV BAIRAGANI — Tue, 25 Aug 2026 09:38:18 GMT

Part Number: CC2755P20
Other Parts Discussed in Thread: UNIFLASH

Hi Team,How to confirm that device is communicating ? does we have any commands to check ? please provide us the assistance on how to communictae with device CC2755P207E0WRHAR

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, , UCC27424

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.