Other wireless technologies forum - Recent Threads

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.

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

Zeya Myint — Tue, 11 Aug 2026 17:41:54 GMT

Any update on this thread? We really need to resolve it. Thanks

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

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

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

Brian Zhou — Fri, 07 Aug 2026 18:26:44 GMT

from above table, to write extended register , TX CMD is 10101111 = AF following address.

to read extended register , TX CMD is 11101111= EF following address.

"payload" 101111b (= 0x2F) is not address "2F"

Regards

Brian

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

Alex Fryer — Fri, 07 Aug 2026 17:25:25 GMT

Hi Brian,

Thanks for the quick reply.

So I understand, what you're saying is that, to write to a register in the extended register space, I must do the following:

1. Call the write command with 6-bit "payload" 101111b (= 0x2F).

2. Send the 8-bit full address

Is this not the same as a standard register write to register 0x2F? And when do I provide the payload I want to write to the extended register (0x80, in my case)?

And I have the same question for a read, I gather it is effectively sending the read command to register 0x2F, followed by the address of the extended register (0x80), then where do I read the value of that register?

Thanks very much for your help,

Alex

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

Brian Zhou — Fri, 07 Aug 2026 16:26:23 GMT

Hi Alex:

All registers can be read and write by ULPI commands. ULPI define TX CMD sent by link and RX CMD sent by PHY.

This table list TX CMD to send test package , extended register read and write.

Registers with *SET and *CLR in TUSB1211 do not physically exist .

Please use TUSB1210 since TUSB1211 was expired.

Best

Brian

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

Zeya Myint — Wed, 05 Aug 2026 20:25:40 GMT

Hi,

I have the SimpleLink Low Power F3 SDK, version 9.20.01.21, installed at C:/ti/simplelink_lowpower_f3_sdk_9_20_01_21.

Here is the codes responsible to generate a key pair and then import it to HSM. The error code -135 returns at psa_import_key().

Thanks in advance,

Zeya

/* PSA Crypto header file */

#include <third_party/mbedtls/include/psa/crypto.h>

/* Driver Header files */

#include <ti/drivers/cryptoutils/hsm/HSMXXF3.h>

#include "psa_crypto_ops.h"

bool psaCryptoOps_ensureKeyExists(bool forceRegenerate)

{

uint8_t existingPublicKey[PSA_CRYPTO_OPS_PUBLIC_KEY_LENGTH];

bool exists = psaCryptoOps_getPublicKey(existingPublicKey);

if (exists && !forceRegenerate)

{

return true;

}

uint8_t rawPrivateKey[PSA_CRYPTO_OPS_PRIVATE_KEY_LENGTH];

/* Diagnostic aside: importing the exact fixed P-256 test vector from the

* base tfm_psaSignVerify example's own README (proven to work there)

* failed identically with -135 - ruling out the key value as a factor.

* Back to fresh random bytes, as intended. */

if (psa_generate_random(rawPrivateKey, sizeof(rawPrivateKey)) != PSA_SUCCESS)

{

return false;

}

if (exists)

{

(void)psa_destroy_key((psa_key_id_t)PSA_APP_KEY_ID);

}

psa_key_attributes_t attributes = PSA_KEY_ATTRIBUTES_INIT;

psa_key_id_t keyId = PSA_APP_KEY_ID;

psa_set_key_id(&attributes, PSA_APP_KEY_ID);

/* PSA_KEY_USAGE_EXPORT was tried here as a diagnostic (does the -135

* INVALID_ARGUMENT depend on usage flags?) - ruled out, still -135 with

* no crash. Reverted: the key must stay non-exportable. */

psa_set_key_usage_flags(&attributes, PSA_KEY_USAGE_SIGN_HASH);

/* A wildcard hash policy (PSA_ALG_HASH_MASK, matching the base

* tfm_psaSignVerify example's working psa_import_key() calls) was tried

* here and reproduced the same self-reset crash psa_import_key() has

* shown throughout this investigation - worse than the concrete

* algorithm below, which at least returns cleanly (with

* PSA_ERROR_INVALID_ARGUMENT). Keeping the concrete algorithm. */

psa_set_key_algorithm(&attributes, PSA_ALG_ECDSA(PSA_ALG_SHA_256));

psa_set_key_type(&attributes, PSA_KEY_TYPE_ECC_KEY_PAIR(PSA_ECC_FAMILY_SECP_R1));

psa_set_key_bits(&attributes, 256);

/* PSA_KEY_LOCATION_HSM_ASSET_STORE crashed the device hard on import on

* the original 0x1000-byte crypto_sp stack (confirmed via live

* debugging - the call never returned, device self-reset). Retesting

* now that crypto_sp's stack has been doubled to 0x2000: static tracing

* shows PSA_KEY_LOCATION_LOCAL_STORAGE's import path routes through

* psa_save_persistent_key() -> psa_crypto_storage_store() ->

* psa_its_set() -> tfm_its_set() (TF-M's ITS/flash storage engine) -

* unexamined territory and a plausible source of the persistent -135.

* PSA_KEY_LOCATION_HSM_ASSET_STORE takes a structurally different path

* (local_LoadPlaintextExport(), pure HSM asset/token mechanism, no

* flash/ITS involvement at all) - also the originally-preferred

* storage backend (genuine hardware-backed non-exportable storage). */

psa_set_key_lifetime(&attributes,

PSA_KEY_LIFETIME_FROM_PERSISTENCE_AND_LOCATION(PSA_KEY_PERSISTENCE_HSM_ASSET_STORE,

PSA_KEY_LOCATION_HSM_ASSET_STORE));

psa_status_t importStatus = psa_import_key(&attributes, rawPrivateKey, sizeof(rawPrivateKey), &keyId);

lastImportStatus = (int32_t)importStatus;

memset(rawPrivateKey, 0, sizeof(rawPrivateKey));

return (importStatus == PSA_SUCCESS);

}

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

Tarek D — Wed, 05 Aug 2026 16:07:46 GMT

Hello,

Thank you for reaching out and I'm sorry to hear you're experiencing issues with using the HSM!

Could you please provide additional information on your project, and how you're using cryptography in your application?

Also, please provide the SDK version you're using.

Best Regards,

Tarek D

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

Jan — Wed, 05 Aug 2026 14:30:43 GMT

Hi,

Thank you for reaching out. Let me loop in the appropriate expert to assist with this.

Best Regards,

Jan

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.

RE: TPS43061: Parts 90 out in tape and reel

Niklas Schwarz — Tue, 04 Aug 2026 08:46:53 GMT

Hi Lamond,

Quick update.
I am still waiting for a statement from our production site.
I will let you know as soon as I receive feedback.

I am sorry for this inconvenience.

Best regards,
Niklas

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?

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

Durga Devi — Sat, 01 Aug 2026 03:47:07 GMT

Hi,

Thanks for confirming the expected frame format — that matches what we're now sending exactly (Flags 0x20, Command 0x20 for Read Single Block, UID transmitted LSB-first).

Wanted to close the loop on this: we found and fixed the actual root cause, and it turned out to be firmware-side, not a protocol or RF issue.

Our Inventory scan handler had an off-by-one bug in how it captured a tag's UID out of the response buffer — it was silently dropping the tag's true first UID byte and substituting a stale/unrelated byte in its place (visible in captures as the tag's mandatory terminal 0xE0 byte landing one position early, with a spurious extra byte after it, instead of 0xE0 correctly being the very last byte). This bug was introduced by an earlier, unrelated fix to a different receive-path issue that shifted where response data landed in our buffer — the Inventory-specific UID capture code was never updated to match the new offset.

Since every addressed command (Select, Read Single Block, Read Multiple Blocks) was addressing tags with this incorrect UID, no tag could ever match it — regardless of flags, timing, or anything else we tried, which is why the failure looked so uniform and protocol-related from the outside.

After fixing the UID capture, addressed commands started working immediately and have now been confirmed reliable across multiple tags and multiple sessions, using exactly the frame format you described.

Thanks for the help and for double-checking the format on your end — appreciated, and this can be marked resolved.

Durga

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

Josh Wyatt — Fri, 31 Jul 2026 15:07:48 GMT

Dear Durga -

here the ISO15693 request to an SLIX2 transponder should be formatted in this way:

Request Flags - 0x20 or 0x22 (low or high data rate)

Command Code - 0x20 (read single block)

UID - LSB first (ie if tag UID is E004010012345678, then you would send 0x78, 0x56 0x34, 0x12, 0x00, 0x01, 0x04, 0xE0

block # to read - your choice, and this should not be a protected block, SLIX2 does have memory locations which are not accessible unles password is also provided (that tag has 78 user memory in blocks 0x00 (0 dec) through 0x4D (77 dec)

---

if above does not help you sort this out, please respond and provide logic analyzer capture of your parallel interface, schematic and antenna tuning details( just to double check those in case something else is going on here) - since you can read out tags un-addressed, i suspect your issue is just protocol related at the moment.

For reference, i used one of our ISO15693 transponders with the TRF7960EVM & GUI to double check this for you, too.

Read single block, addressed

Write single block, addressed

Reading it back, addressed

RE: TPS43061: Parts 90 out in tape and reel

Niklas Schwarz — Fri, 31 Jul 2026 07:36:42 GMT

Hi Lamond,

Thanks for the lot code.
I forwarded the details and I am now in contact with the production site.

I will give you an update on my findings by beginning of next week.
Thanks a lot for your patience.

Best regards,
Niklas

RE: TPS43061: Parts 90 out in tape and reel

Lamond Bauman — Thu, 30 Jul 2026 15:47:42 GMT

Let me know if this comes through OK.

RE: TPS43061: Parts 90 out in tape and reel

Niklas Schwarz — Thu, 30 Jul 2026 15:40:13 GMT

Hi Lamond,

I directly received some feedback.
We need to report this with our with our production side.
Can you give me the number of the lot trace code? This code can be found on the reel package.
This is require to track down where the ICs have been packaged.

Thanks and best regards,
Niklas

RE: TPS43061: Parts 90 out in tape and reel

Niklas Schwarz — Thu, 30 Jul 2026 14:50:58 GMT

Hi Lamond,

Thanks for the quick feedback.
I have never run into such a problem in the past, so I forwarded this case internally to our product engineers to ask how something like this can happen.

I will get back to you once I received feedback (hopefully tomorrow, but latest by beginning of next week)

Best regards,
Niklas

RE: TPS43061: Parts 90 out in tape and reel

Lamond Bauman — Thu, 30 Jul 2026 14:20:33 GMT

Niklas this actually happened on 7/29 during production. We were 42 boards deeps and all of a sudden 9 IC's were roatated 90 in the tape and reel. Then after that they were all back to normal rotation.

RE: TPS43061: Parts 90 out in tape and reel

Niklas Schwarz — Thu, 30 Jul 2026 07:12:50 GMT

Hi Lamond,

Thanks for using the e2e forum.

So your concern is about an IC that is rotated by 90° within the package reel, correct?
Is this a problem that actually happened with your TPS43061 order, or this is just a question about probability and risk assessment?

Thanks a lot for your clarification.

Best regards,
Niklas

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

Jack Guan — Wed, 29 Jul 2026 16:08:39 GMT

Hi Melissa,

Please see the below link to reference the MSL level:

https://www.ti.com/packaging/docs/mslsearch.tsp?OPN=LSF0102QDCURQ1&searchSelected=devpartno&searchkey=LSF0102QDCURQ1#divline

For devices received from HFT assembly site, the MSL level is Level-1-260C-UNLIM.

Regards,

Jack

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.

CC2652R: Guidance Required for Passive Keyless Entry Key Fob Development

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

Part Number: CC2652R

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

RE: CC2652R: Guidance Required for Passive Keyless Entry Key Fob Development

Jan — Fri, 24 Jul 2026 20:25:55 GMT

Hi Ram,

Happy to help! I believe channel sounding will be applicable to your use-case. I have seen good measurement results in the 10s of meters range which should work well for what youa re looking to implement. The antenna design is critically important for CS. There are a few different antenna design configurations. Typically having more antennas is better for performance but this will depend on factors like the expected environment and housing. I recommend reading details on how CS works at the theoretical level to see how it may impact the performance. The following app note is useful: https://www.ti.com/lit/swra791

For programming, you may use CCS or uniflash. We also support J-Link. For authentication, CS uses standard BLE pairing and authentication. I recommend referencing some of the Bluetooth LE simplelink academy labs to learn more.

Best Regards,

Jan

RE: CC2652R: Guidance Required for Passive Keyless Entry Key Fob Development

Ramkumar Ramasamy — Fri, 24 Jul 2026 01:28:39 GMT

Hi Jan,

Good day!

Thank you for sharing the document. I have gone through it, and I have a few questions.

My application is for gate access. I will be inside my car while approaching the gate. Will the system be able to detect and allow access in this situation? If yes, what is the maximum reading range or operating distance?

I understand that the reading range may depend on the antenna. Could you please explain this in more detail? In the reference design, I noticed that two antennas are used. For my application, do I need one antenna or two? Also, how can I achieve the required reading range for vehicle access?

I also have a few questions about the programming. Could you please explain how the programming works and how the authentication process works? I'm finding it a little difficult to understand from the document.

If you have any additional documents or guides that explain the system in more detail, could you please share them with me?

Thank you, and I look forward to your reply.

Best regards,
Ram.