https://e2e.ti.com/support/wireless-connectivity/other-wireless-group/other-wireless/<p style="display:none;">blank</p>en-USTelligent Community 13https://e2e.ti.com/support/wireless-connectivity/other-wireless-group/other-wireless/f/other-wireless-technologies-forum/1673194/lp-em-cc2745r10-q1-tf-m-secure-image-tfm_s-axf-fails-to-load-cc2745r10-q1/6451674Sat, 15 Aug 2026 01:14:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:06d1acc3-435a-47fc-b00a-1952c43608faRyan Brown1I could only find one similar E2E thread, which CCS version are you using? [FAQ] CC2745R10-Q1: CCS 20.3.0 Secure Debug Manager libary not loaded I will ask an expert whether they have encountered anything similar. Regards, Ryanhttps://e2e.ti.com/support/wireless-connectivity/other-wireless-group/other-wireless/f/other-wireless-technologies-forum/1673194/lp-em-cc2745r10-q1-tf-m-secure-image-tfm_s-axf-fails-to-load-cc2745r10-q1/6451260Fri, 14 Aug 2026 15:31:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:e6642f5e-95ec-474e-ab0b-ce974af10846Zeya MyintHi Ryan, Thanks for quick reply and additional information. Unlike other posts, my issue is only applied to flashing the secure TF-M firmware (tfm_s.axf). I can still flash and run other non-secure firmware successfully. For that reason, I doubt it is a faulty connection between the XDS110 and CC2745R10-Q1. We are developing security related cryptography applications and relied heavily on the secure Trust Zone (TF-M) firmware from SimpleLink. I had multiple mass erases after every attempt of secure flashing. Regards, Zeyahttps://e2e.ti.com/support/wireless-connectivity/other-wireless-group/other-wireless/f/other-wireless-technologies-forum/1673194/lp-em-cc2745r10-q1-tf-m-secure-image-tfm_s-axf-fails-to-load-cc2745r10-q1/6451127Fri, 14 Aug 2026 13:38:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:d88d602b-4b53-44ff-9fc0-dd119a91619dRyan Brown1Hi Zeya, Error -615 is typically due to the target not seeing a correctly formatted SWD header. See these relevant E2E threads . This is typically caused by a faulty connection between the XDS110 and CC2745R10-Q1. Have you also tried mass erasing the device? Please also look at similar E2E threads on this topic. Regards, Ryanhttps://e2e.ti.com/support/wireless-connectivity/other-wireless-group/other-wireless/f/other-wireless-technologies-forum/1673265/cc2651r3-enable-power-down-mode/6451116Fri, 14 Aug 2026 13:27:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:5cc24f8c-c759-4f2c-8a17-d0e0660f0d1cRyan Brown1Hi Reshmi, The Power TI Driver automatically accomplishes the task of putting the MCU to sleep when the RTOS has the device in an idle loop. You can reference the gpiointerrupt example for low-power operation with GPIO interrupts and further incorporate ClockP for the 30-second timing. You can evaluate with the LAUNCHXL-CC26x2R1 with steps for porting to the CC2651R3 Regards, Ryanhttps://e2e.ti.com/support/wireless-connectivity/other-wireless-group/other-wireless/f/other-wireless-technologies-forum/1673265/cc2651r3-enable-power-down-modeFri, 14 Aug 2026 07:01:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:939113a0-64a8-413f-93b4-1d7e9f26fd99Reshmi senanPart 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.LAUNCHXL-CC26X2R1Wireless InfrastructureCC2651R3https://e2e.ti.com/support/wireless-connectivity/other-wireless-group/other-wireless/f/other-wireless-technologies-forum/1673194/lp-em-cc2745r10-q1-tf-m-secure-image-tfm_s-axf-fails-to-load-cc2745r10-q1Fri, 14 Aug 2026 00:13:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:8f07f141-10c7-4c70-99b2-876b70ea967fZeya MyintPart 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&#39;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() → &quot;Unable to authenticate with Secure Debug Manager!&quot; . Sometimes accompanied by Error -615LP-EM-CC2745R10-Q1Wireless InfrastructureCC2745R10-Q1https://e2e.ti.com/support/wireless-connectivity/other-wireless-group/other-wireless/f/other-wireless-technologies-forum/1673024/tms3705-tms3705-and-tms37145---communication-errorThu, 13 Aug 2026 11:36:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:9e422bae-fd1d-465c-91f5-da27e647dffdVijay PawarPart 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 PawarTMS37145Body Electronics &amp; LightingTMS3705https://e2e.ti.com/support/wireless-connectivity/other-wireless-group/other-wireless/f/other-wireless-technologies-forum/1668795/tps43061-parts-90-out-in-tape-and-reel/6448443Wed, 12 Aug 2026 14:26:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:707b40dc-296b-4649-9472-0e14905f3314Niklas SchwarzHi Lamond, It is still taking time to retrieve the initial lot history. In the meantime, the production side asked if you could also provide pictures of the affected units and note down the marking on the IC (besides the &quot;Q&quot;). Apparently such a case is extremely rare, so investigation takes quite some time. Thanks and best regards, Niklashttps://e2e.ti.com/support/wireless-connectivity/other-wireless-group/other-wireless/f/other-wireless-technologies-forum/1670433/simplelink-lowpower-f3-sdk-failed-to-import-generate-ecc-private-key-into-cc2745r10-hsm/6447237Tue, 11 Aug 2026 17:41:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:08ebaae7-bbdc-4ec2-b3e1-6c1ea53f4206Zeya MyintAny update on this thread? We really need to resolve it. Thankshttps://e2e.ti.com/support/wireless-connectivity/other-wireless-group/other-wireless/f/other-wireless-technologies-forum/1671394/tusb1211-vendor-specific-register-access-on-usb-phy-from-stm32-ulpi-viewport/6444314Fri, 07 Aug 2026 18:26:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:720b675c-6175-4586-b875-367583e3abd7Brian Zhoufrom above table, to write extended register , TX CMD is 10101111 = AF following address. to read extended register , TX CMD is 11101111= EF following address. &quot;payload&quot; 101111b (= 0x2F) is not address &quot;2F&quot; Regards Brianhttps://e2e.ti.com/support/wireless-connectivity/other-wireless-group/other-wireless/f/other-wireless-technologies-forum/1671394/tusb1211-vendor-specific-register-access-on-usb-phy-from-stm32-ulpi-viewport/6444268Fri, 07 Aug 2026 17:25:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:4c10a10f-99dd-4a98-ba6c-76e94e4d0871Alex FryerHi Brian, Thanks for the quick reply. So I understand, what you&#39;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 &quot;payload&quot; 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, Alexhttps://e2e.ti.com/support/wireless-connectivity/other-wireless-group/other-wireless/f/other-wireless-technologies-forum/1671394/tusb1211-vendor-specific-register-access-on-usb-phy-from-stm32-ulpi-viewport/6444200Fri, 07 Aug 2026 16:26:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:433a8aa3-d00e-4e5b-9007-d9ddc458472bBrian ZhouHi 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 Brianhttps://e2e.ti.com/support/wireless-connectivity/other-wireless-group/other-wireless/f/other-wireless-technologies-forum/1671394/tusb1211-vendor-specific-register-access-on-usb-phy-from-stm32-ulpi-viewportFri, 07 Aug 2026 07:52:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:52fdc554-3dcf-4aec-89ab-22a67a85fc85Alex FryerPart Number: TUSB1211 Other Parts Discussed in Thread: TUSB1210 Hi, I&#39;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 &quot;extended register space&quot; (addresses &gt; 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&#39;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, AlexTUSB1211TUSB1210https://e2e.ti.com/support/wireless-connectivity/other-wireless-group/other-wireless/f/other-wireless-technologies-forum/1670433/simplelink-lowpower-f3-sdk-failed-to-import-generate-ecc-private-key-into-cc2745r10-hsm/6441372Wed, 05 Aug 2026 20:25:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:db51cbfc-fa47-4da7-8d70-24624ecd5590Zeya MyintHi, 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 /* Driver Header files */ #include #include &quot;psa_crypto_ops.h&quot; bool psaCryptoOps_ensureKeyExists ( bool forceRegenerate ) { uint8_t existingPublicKey [PSA_CRYPTO_OPS_PUBLIC_KEY_LENGTH]; bool exists = psaCryptoOps_getPublicKey (existingPublicKey); if (exists &amp;&amp; !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&#39;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 (&amp;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 (&amp;attributes, PSA_KEY_USAGE_SIGN_HASH); /* A wildcard hash policy (PSA_ALG_HASH_MASK, matching the base * tfm_psaSignVerify example&#39;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 (&amp;attributes, PSA_ALG_ECDSA (PSA_ALG_SHA_256)); psa_set_key_type (&amp;attributes, PSA_KEY_TYPE_ECC_KEY_PAIR (PSA_ECC_FAMILY_SECP_R1)); psa_set_key_bits (&amp;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&#39;s stack has been doubled to 0x2000: static tracing * shows PSA_KEY_LOCATION_LOCAL_STORAGE&#39;s import path routes through * psa_save_persistent_key() -&gt; psa_crypto_storage_store() -&gt; * psa_its_set() -&gt; tfm_its_set() (TF-M&#39;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 (&amp;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 (&amp;attributes, rawPrivateKey, sizeof (rawPrivateKey), &amp;keyId); lastImportStatus = ( int32_t )importStatus; memset (rawPrivateKey, 0 , sizeof (rawPrivateKey)); return (importStatus == PSA_SUCCESS); }https://e2e.ti.com/support/wireless-connectivity/other-wireless-group/other-wireless/f/other-wireless-technologies-forum/1670433/simplelink-lowpower-f3-sdk-failed-to-import-generate-ecc-private-key-into-cc2745r10-hsm/6441078Wed, 05 Aug 2026 16:07:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:76e38a8b-5b00-4d25-9053-6f675d243996Tarek DHello, Thank you for reaching out and I&#39;m sorry to hear you&#39;re experiencing issues with using the HSM! Could you please provide additional information on your project, and how you&#39;re using cryptography in your application? Also, please provide the SDK version you&#39;re using. Best Regards, Tarek Dhttps://e2e.ti.com/support/wireless-connectivity/other-wireless-group/other-wireless/f/other-wireless-technologies-forum/1670433/simplelink-lowpower-f3-sdk-failed-to-import-generate-ecc-private-key-into-cc2745r10-hsm/6440918Wed, 05 Aug 2026 14:30:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:29d0a2f9-b0e6-45bd-a070-60ee16c1eb7bJanHi, Thank you for reaching out. Let me loop in the appropriate expert to assist with this. Best Regards, Janhttps://e2e.ti.com/support/wireless-connectivity/other-wireless-group/other-wireless/f/other-wireless-technologies-forum/1670433/simplelink-lowpower-f3-sdk-failed-to-import-generate-ecc-private-key-into-cc2745r10-hsmWed, 05 Aug 2026 01:42:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:bd97e7a4-a406-4890-a22e-75725f322284Zeya MyintPart 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 &#39;s stack ( 0x1000 → 0x2000 ) via a full TF-M rebuild fixed psa_import_key() &#39;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.simplelink-lowpower-f3-sdkhttps://e2e.ti.com/support/wireless-connectivity/other-wireless-group/other-wireless/f/other-wireless-technologies-forum/1668795/tps43061-parts-90-out-in-tape-and-reel/6438854Tue, 04 Aug 2026 08:46:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:c9094343-2689-42f3-9ff9-fa326a4e2f8fNiklas SchwarzHi 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, Niklashttps://e2e.ti.com/support/wireless-connectivity/other-wireless-group/other-wireless/f/other-wireless-technologies-forum/1669363/trf7960-trf7960-parallel-interface-stm32-host-iso15693-addressed-mode-commands-never-receive-a-tag-response-non-addressed-identical-commands-work-reliably/6436707Sat, 01 Aug 2026 03:47:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:b15ede32-c60e-43bd-9620-0b6fd0fc4097Durga DeviHi, Thanks for confirming the expected frame format — that matches what we&#39;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&#39;s UID out of the response buffer — it was silently dropping the tag&#39;s true first UID byte and substituting a stale/unrelated byte in its place (visible in captures as the tag&#39;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. Durgahttps://e2e.ti.com/support/wireless-connectivity/other-wireless-group/other-wireless/f/other-wireless-technologies-forum/1669363/trf7960-trf7960-parallel-interface-stm32-host-iso15693-addressed-mode-commands-never-receive-a-tag-response-non-addressed-identical-commands-work-reliably/6436094Fri, 31 Jul 2026 15:07:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:c69090fe-384d-408c-b74a-57f1c40df76dJosh WyattDear 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 &amp; GUI to double check this for you, too. Read single block, addressed Write single block, addressed Reading it back, addressed