API solutions Forum - Recent Threads

LMR33640: I entered a request for LMR33640DDDAR for a quantity of 222 units, the system rounded the quantity to a standard pack (SPQ)

Eran Hass — Mon, 03 Aug 2026 08:41:39 GMT

Part Number: LMR33640

Hello Support,
How are you?
I placed a request for LMR33640DDDAR for a quantity of 222 units, the system rounded the quantity to a standard package (SPQ)
This is intentional behavior by TI, TI does not sell partial quantities — it only sells whole packages.

I requested 222
The standardPackQuantity (SPQ) of this product is 2500 (this is a very common value — appears 1,823 times in my blogs)
222 < 2500, so TI rounds up to the first standard package = 2500
The "minimum 50 units" written on the TI website is the MOQ (Minimum Order Quantity) — the lower threshold. But the SPQ (Standard Pack Quantity) controls the package size. When SPQ is greater than MOQ, SPQ determines the actual quantity.

Important: My code already stores the two quantities separately — that's why we see both 222 (Requested Qty) and 2500 (Quantity) in the table. The system works correctly; TI simply forces whole packages.

Is it possible to order less than 2500? Not through this API. This is TI policy. If you want a smaller quantity — only through the TI website directly or through a distributor (TI allows small orders only through certain channels).

1. Can I order a small quantity through the website and not through the API?
2. Do you think this is correct behavior of the system? Because these are the answers I get from TI
3. Is it true that TI recommends contacting their distributors to purchase in small quantities? (Mouser, DigiKey) Which distributors I saw online
4. How would you recommend I explain this to the customer?

Thank you very much

Best regards
Elisha

DLP4710EVM-LC: Recommended initialization sequence for splash pattern projection

Yi Tian Kok — Mon, 03 Aug 2026 06:14:57 GMT

Part Number: DLP4710EVM-LC

Hi TI Team,

I am a member of the Software Development Team and we are currently developing software for the DLP4710EVM-LC using the DLPC34xx API.

We are implementing splash pattern projection and would like to confirm the recommended initialization sequence for the following API calls.

Our current initialization performs:

DLPC34XX_WriteRgbLedCurrent()
DLPC34XX_WriteRgbLedEnable()
DLPC34XX_WriteTriggerOutConfiguration()
DLPC34XX_WritePatternConfiguration()
DLPC34XX_WriteOperatingModeSelect(DLPC34XX_OM_SENS_SPLASH_PATTERN)
DLPC34XX_WriteSplashScreenSelect()
DLPC34XX_WriteSplashScreenExecute()

Could you please confirm whether this is the correct order for displaying a preloaded splash image?

In particular, we would like to know:

Should WriteRgbLedCurrent() be called before or after WriteRgbLedEnable()?
Is WriteTriggerOutConfiguration() required before entering Splash Pattern mode?
Should WritePatternConfiguration() be called before WriteOperatingModeSelect(), or after?
Are there any required delays or additional commands between these API calls?
Is there a recommended initialization sequence from TI for displaying splash images on the DLP4710EVM-LC?

The reason we ask is that DLPC34XX_WritePatternConfiguration() returns success, but DLPC34XX_WriteOperatingModeSelect(DLPC34XX_OM_SENS_SPLASH_PATTERN) returns an error, and the projector appears to stop projecting immediately afterwards.

Any guidance on the correct initialization sequence or common causes of this behavior would be greatly appreciated.

Thank you.

AM263P4-Q1: Establishing PTP/E2E stack

Kevin DeVries — Thu, 30 Jul 2026 13:54:10 GMT

Part Number: AM263P4-Q1

Starting from the icss_emac_lwip example, I was hoping to add PTP/E2E protocol to the ethernet stack.

The documentation (https://software-dl.ti.com/mcu-plus-sdk/esd/AM64X/latest/exports/docs/api_guide_am64x/ICSS_TIMESYNC.html) is excessively vauge and unuseful (e.g. comments like "Please check all members inside TimeSync_ParamsHandle structure", with structure fields are named and not described). The API documentation (https://software-dl.ti.com/mcu-plus-sdk/esd/AM64X/latest/exports/docs/api_guide_am64x/group__NETWORKING__ICSS__TIMESYNC__MODULE.html) isn't useful with 1-2 sentence comments. I looked at some of the code base, and it's not any more clarifying.

I've looked on-line and tried two different AIs to help me get the fundamentals working. The AI's are halucinating, and I couldn't find a step-by-step article to set up PTP/E2E.

Do you have anything that can help me? Short of that, can you provide me a working example? I saw the gPTP example and got that working, but that's peer-to-peer, and I need end-to-end.

Thanks for the help!

Kevin

AM62P: Only Validate First boot stage in fused HS-SE device

Hakan Cankaya — Fri, 24 Jul 2026 08:59:39 GMT

Part Number: AM62P

Hello,

We have fused device, mainly for JTAG locking. Secure boot is no requirement, therefor we only want to verify the first boot stage (TIBOOT image via ROM Code) and then not verify anymore images afterwards. We are using the SDK for loading the RPRC images, therefor the API for authentication is automatically called. We can alter the code, but is there a cleaner way to do this (e.g. by setting a parameter or compiler flag etc.).

Thanks

Hakan

MSP430-FLASHER: Unable to download ti_msp430driver_setup_1.0.1.1-windows.zip – download link returns an error

Nathan Lacroix — Fri, 24 Jul 2026 07:41:54 GMT

Part Number: MSP430-FLASHER

Hello,
I am trying to download the ti_msp430driver_setup_1.0.1.1-windows.zip driver for my MSP430 Programmer.

I am logged into myTI and I receive the download link by email. However, the download does not start automatically. When I click the manual download link, I am redirected to an error page.

I have tried several times, on several computers and networks, and the issue persists. Could you please provide a working download link or help me access the driver?

Browser: Google Chrome on Windows 11
Board: MSP430 Programmer
Software/driver: ti_msp430driver_setup_1.0.1.1-windows.zip

TMS320F28P659SH-Q1: Request for Memory Stack APIs for NvM → MemIf → Ea → EEPROM

Ngu Do — Wed, 22 Jul 2026 02:21:05 GMT

Part Number: TMS320F28P659SH-Q1

Request for Memory Stack APIs for NvM → MemIf → Ea → EEPROM

Hello TI Team,

I am currently developing an AUTOSAR-based application on a TI C2000 MCU and would like to clarify my previous request regarding memory read/write APIs.

I believe my previous question may have been misunderstood as a request for Flash programming APIs such as Fapi_issueProgrammingCommand(). However, this is not what I am looking for.

My requirement is to have a memory abstraction stack compatible with the AUTOSAR architecture, for example:

Application
    ↓
   NvM
    ↓
  MemIf
    ↓
    Ea
    ↓
 EEPROM / Emulated EEPROM
    ↓
TI MCU Flash / EEPROM hardware

More specifically, I am looking for APIs or TI-supported implementations that allow the AUTOSAR NvM module to perform persistent data storage through the lower memory abstraction layers.

For example, I would like to have functionality equivalent to:

NvM_WriteBlock()
    ↓
MemIf_Write()
    ↓
Ea_Write()
    ↓
EEPROM / Emulated EEPROM Driver
    ↓
TI Flash / EEPROM hardware

and:

NvM_ReadBlock()
    ↓
MemIf_Read()
    ↓
Ea_Read()
    ↓
EEPROM / Emulated EEPROM Driver
    ↓
TI Flash / EEPROM hardware

I am not asking for a low-level Flash programming API only. APIs such as Fapi_issueProgrammingCommand() are useful for directly programming Flash memory, but they do not provide the AUTOSAR memory abstraction required between NvM, MemIf, and Ea.

Could you please clarify whether TI provides any of the following:

An AUTOSAR-compatible Ea (EEPROM Abstraction) implementation.
An AUTOSAR-compatible MemIf implementation or integration example.
An EEPROM Emulation driver that can be integrated with Ea.
An example showing how NvM can be connected to TI Flash-based EEPROM Emulation.
Recommended TI APIs or drivers for implementing the following flow:

NvM
 ↓
MemIf
 ↓
Ea
 ↓
EEPROM Emulation
 ↓
TI Flash Driver / FAPI
 ↓
C2000 Flash

If TI does not provide the complete AUTOSAR stack, could you please provide guidance or reference implementations for the Ea and EEPROM Emulation layers that should be placed above the TI Flash API?

The main goal is to implement persistent NVM storage following the AUTOSAR architecture, where the application interacts with NvM and does not directly call TI Flash programming APIs.

Thank you for your clarification and support.

AM2434: In EtherCAT sub-devices, the callback for reading input process data may not be invoked in some cases. (Continued)

?? ?? — Mon, 20 Jul 2026 04:56:16 GMT

Part Number: AM2434
Other Parts Discussed in Thread: TMDS64EVM, LP-AM243

Hello, Developer Team.

#1621803
Since the previous thread was locked, I am posting the continuation here.
(Please note that I am posting this as a "New Question" because the "Related Questions" section did not appear.)

After asking my last question in the previous thread, I investigated the sub-device processing further and discovered the following:

While the Sync0_Isr call interval was 250 µs, the PDI_Isr call interval was approximately 310 µs. Consequently, roughly every four cycles, the Sync0_Isr was triggered before the PDI_Isr, creating the appearance that the output was not being updated every 1 ms. (Synchronization setting: DC synchronization with a 250 µs cycle time.)

Additionally, having noted in another thread that CPU load reaching 100% could potentially delay sub-device processing timing, I used the FreeRTOS Run Time Statistics feature to measure the CPU usage of each task while in the OP state.

Below are the test results obtained by taking measurements every second over a 10-second test period.

Based on these results, the IDLE task accounts for a significant portion of the CPU load; therefore, it appears that the phenomenon where output updates are skipped is not caused by the CPU processing load.

Given this information, could you please assist me in resolving this issue?

Kind regards,

AM2431: Inquiry Regarding CRA Compliance and Industrial Ethernet Security Support

Lee Uie-Tae — Thu, 16 Jul 2026 07:58:05 GMT

Part Number: AM2431

Dear TI Support,

We are currently developing an industrial communication device based on the AM243x platform using the TI Industrial Communications SDK. Our device supports PROFINET IO-Device, EtherNet/IP Adapter, and Modbus TCP.

As part of our preparation for the EU Cyber Resilience Act (CRA), we are evaluating whether our current product can support the required industrial communication security features.

Could you please provide information on the following?

PROFINET
- Does the TI Industrial Communications SDK have a roadmap to support PROFINET V2.5 Secure Access and Secure Realtime?
- If yes, is there an expected release schedule?
EtherNet/IP
- Does the EtherNet/IP stack provided with the TI Industrial Communications SDK support CIP Security?
- If not, is there a roadmap or any recommended solution for implementing CIP Security on AM243x?
Modbus TCP
- Does TI provide any reference implementation or example for Modbus Security (TLS) on the AM243x platform?
Security Libraries
- Which TLS/DTLS libraries are officially recommended for use with the Industrial Communications SDK (for example, mbedTLS or wolfSSL)?
- Are there any reference examples for integrating TLS/DTLS with industrial communication protocols on AM243x?

Any guidance, roadmap information, or relevant documentation would be greatly appreciated.

Thank you for your support.

Best regards,

AM2434: Question about I2C_transfer() timeout handling and EEPROM read not returning / AM2434

Shimodome Ryo — Thu, 09 Jul 2026 05:16:28 GMT

Part Number: AM2434
Other Parts Discussed in Thread: SYSCONFIG

Hello,

We are experiencing an issue where an EEPROM read does not return, and while investigating the cause we would like to confirm a few points regarding the I2C driver behavior.

■ Environment

SDK: ind_comms_sdk_am243x_2025_00_00_08 and mcu_plus_sdk_11_01_00_19
Device: AM2434
I2C configuration (Sysconfig):
- Transfer Mode: Blocking
- Enable Interrupt: Enabled
- Bit Rate: 100 kHz, I2C Instance: I2C0, I2C Address: 0x50 (AT24C)

■ Symptom

When reading the EEPROM via EEPROM_AT24C_read(), the call sometimes does not return.
It does not happen every time; after rebooting, it reproduces roughly 1 out of 3 times.
If we insert a delay of about 100 us immediately before the read, the issue no longer reproduces.

■ What we have confirmed so far

In EEPROM_AT24C_read(), transaction->timeout is not set, so it keeps its initial value of SystemP_WAIT_FOREVER (-1). Because of this, when the issue occurs, the code appears to wait forever and the read never returns.
As a test, we set timeout to 100000. After this, the processing continues once the timeout period elapses (it no longer waits forever).
However, the read function does not return a timeout error and is treated as a successful completion, even though the EEPROM data is actually not read.
Note: we have not verified the initial value of transaction->status.

■ Questions

1. Regarding the return value behavior of I2C_transfer() With Transfer Mode = Blocking and Enable Interrupt = Enabled, we looked at I2C_transfer(). It appears that when SemaphoreP_pend() times out, retVal is first set to SystemP_TIMEOUT, but then in the interrupt-mode branch (the enableIntr == true path), retVal is overwritten by retVal = transaction->status;. In this case, unless transaction->status has been updated to I2C_STS_ERR_TIMEOUT, we suspect that a successful completion (SystemP_SUCCESS) is returned even though a timeout actually occurred. Is this the intended behavior? Could you please confirm whether this is expected behavior or a defect? Relevant location: I2C_transfer() in C:\ti\mcu_plus_sdk_am243x_11_01_00_19\source\drivers\i2c\v0\i2c_v0.c

2. Regarding the likely root cause of the timeout Could you advise on the possible reasons why a timeout (a wait that never completes) occurs during the read in the first place? Since it reproduces roughly 1 out of 3 times and disappears when we insert about a 100 us delay just before the read, we suspect that the EEPROM may not yet be ready (not fully powered up) right after power-on, i.e., a device start-up timing issue. Could you share your view on whether this assumption is reasonable, and any other possible causes?

3. Regarding an immediate workaround Separately from the root-cause fix in item 2, could you advise on any workaround or recommended action we can apply right now on our side? (Currently the 100 us delay before the read works around the issue, but we consider it only a temporary measure.)

Best regards,

AM2434: Inquiry: Frame-Loss Tolerance of PRU-ICSS EtherCAT Slave Sample in DC Sync Mode

Shimodome Ryo — Tue, 07 Jul 2026 22:58:02 GMT

Part Number: AM2434

Dear TI Support Team,

We are developing an EtherCAT slave device using your Industrial Communications SDK, and would like your guidance on the recommended approach to improve frame-loss tolerance in DC Sync mode.

Environment

Target device: AM2434
Industrial Communications SDK version: 2025_00_00_08
Synchronization mode: DC Sync (SYNC0 enabled)
Cycle time: 500 µs

Our Goal

We would like the slave to remain in the OP state even when several process data frames (e.g., 5 to 10 frames) are lost consecutively, while continuing to use DC synchronization.

Questions

In DC Sync mode, with the default TI sample configuration, after how many consecutive lost process data frames does the slave transition from OP to SAFEOP? Also, which AL Status Code is reported in that case?
Could you advise the simplest way to increase frame-loss tolerance? We are considering the following options:
- (a) Modifying only the initial values of ESC registers
- (b) Modifying only the ESI XML / EEPROM settings
- (c) Modifying the TI sample source code
Are there any side effects we should be aware of when applying such changes — for example, DC clock drift, SYNC0 jitter, or impact on ETG Conformance Test compliance?

Thank you very much for your support. We look forward to your response.

Best regards,

AM6442: Combined Keyring (Signed and Encrypted) Import Failure

ZHEN BEI SIN — Tue, 07 Jul 2026 15:39:36 GMT

Part Number: AM6442

Issue : Combined Keyring (Signed and Encrypted) Import Failure

A combined keyring (asymmetric key + symmetric key) was generated and packaged as a signed-and-encrypted image. (keyring.bin)
The KEYRING import operation fails with return code -19.

Reference:

KEYRING Documentation: https://software-dl.ti.com/tisci/esd/latest/6_topic_user_guides/keyring.html

TI E2E FAQ: https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1484330/faq-sysfw-keyring-importing-support-on-am62x

Patch: 0001-calling-sysfw-keyring-import-API-in-r5-spl.patch: calling sysfw keyring import API in r5-spl

The example provided in keyring_init.h appears to cover only:

Single keyring images (Signed-only)

Question

Can TI provide a valid combined keyring (asymmetric key + symmetric key) signed by SMPK and encrypted by SMEK sample image for reference?
Is importing a combined keyring in signed-and-encrypted format supported on AM64x HS-SE devices?
Is there any known limitation or additional requirement when importing a signed-and-encrypted combined keyring on AM64x HS-SE devices?

AM6442: HS-SE tiboot3 Flash Read Issue

ZHEN BEI SIN — Tue, 07 Jul 2026 15:35:59 GMT

Part Number: AM6442

Issue: HS-SE tiboot3 Unable to Read Flash Data.

On the AM64x HS-FS platform, tiboot3 is able to successfully read NOR flash contents using tiboot3-am64x_sr2-hs-fs-evm.bin.
On the AM64x HS-SE platform, tiboot3 is unable to read NOR flash contents using tiboot3-am64x_sr2-hs-evm.bin.
From the API perspective, the flash read operation completes successfully; however, the returned buffer contains only 0x00 data.
Verification confirms that valid data exists in the flash region. The same region can be read correctly from U-Boot using the sf read command.
This behavior suggests that access to the Flash SubSystem (FSS) may be restricted on the HS-SE device, potentially due to firewall configuration or security settings.

Question:

Is there any method to check whether firewall configuration is affecting flash access, or any additional information about firewall settings that could impact flash reads on AM64x HS-SE in tiboot3?

AM263X-MCAL-SDK: Bitrate Calculation for CAN Communication On AM2634 Controller

Harika Badri — Tue, 07 Jul 2026 03:41:16 GMT

Part Number: AM263X-MCAL-SDK
Other Parts Discussed in Thread: AM2634, SYSCONFIG

Hi TI Team,

I am working on the AM2634 MCU using the MCU+ SDK MCAN driver.

I would like to understand the complete CAN bit rate calculation used by the AM2634 MCAN peripheral.

From the MCU+ SDK documentation, I understand that the nominal bit rate is calculated as:

Bit Rate = CAN Clock / (BRP × (1 + TSEG1 + TSEG2)),BUT i am not getting the exact value while using this formula.give the brief explanation on this.

Thank you for your support.

AM263X-MCAL-SDK: AM2634 MCAN Mailbox Support

Harika Badri — Wed, 01 Jul 2026 06:25:02 GMT

Part Number: AM263X-MCAL-SDK
Other Parts Discussed in Thread: AM2634

Hi TI Team,

I am developing a BMS application on the AM2634 using the MCAN peripheral.

I have the following questions:

Does the AM2634 MCAN support the traditional Mailbox-based CAN communication, or does it only support Message RAM with TX Buffers, RX Buffers, and RX FIFOs?
If mailbox support is available:
- Is there any MCU+ SDK example.
- How are mailboxes configured for transmit and receive.
If mailbox support is not available:
- Is it recommended to use dedicated TX Buffers as mailboxes for periodic CAN messages?Does the MCAN peripheral support eDMA for CAN transmit and receive?
  - If yes, is there any SDK example or reference available.
For an automotive BMS application with periodic CAN messages, which approach does TI recommend.
- MCAN TX Buffers (mailbox-like implementation)
- MCAN with eDMA

Could you also provide any reference documents or examples explaining the recommended implementation.

Thank you.

TLA2024EVM-PDK: TLA2024EVM-PDK CDC USB API

耀生黃 — Mon, 29 Jun 2026 08:33:54 GMT

Part Number: TLA2024EVM-PDK
Other Parts Discussed in Thread: ADS1115, TLA2024

How can I read the TLA2024EVM-PDK via the USB serial port without using a web GUI?

Do you have any programmable design guidelines I can refer to?

best regard

Walson

TMS570LC4357: Not able to get CSP for Halcogen generated drivers

Deepak M — Thu, 25 Jun 2026 07:42:49 GMT

Part Number: TMS570LC4357
Other Parts Discussed in Thread: HALCOGEN

Hello,

We would need CSP for TMS570LC4357 MCU halcogen generated drivers.

Kindly let us know how we have to proceed.

TMS320F280025C: TMS320F280025C Flash API Source Code Request

Hakan TOPUZ — Wed, 17 Jun 2026 07:13:19 GMT

Part Number: TMS320F280025C

I am a member of the Software Development Team. We are currently working with the TMS320F280025C microcontroller from the C2000 family and developing a custom bootloader. Therefore, we would like to request access to the source code of the Flash API related to this device.

Can you help us with this?

NOTE: We already have an NDA agreement in place.

AM62A7: AM62A7: Occasional startup failure of C7x

yangtian yi — Mon, 15 Jun 2026 07:34:00 GMT

Part Number: AM62A7

During the development of our product software, we utilize the SBL boot mode. We have observed that during multiple repeated restarts, the IPC communication between A53 and C7x sometimes fails to establish at startup, with the specific error shown in the figure below. However, at this time, the IPC communication between A53 and other cores, such as MCU R5, is normal. I found a link on the forum where the situation encountered by the user is similar to ours. Furthermore, he ultimately found a potential solution to the problem.

AM62A7: Power-on probability does not display the camera image - Processors forum - Processors - TI E2E support forums

We are unsure whether this solution is reasonable and hope that TI experts can provide an answer based on our error report and the issues mentioned in the link

AM625-Q1: The issue regarding the DebugP_log printing function

zhaoneng deng — Fri, 12 Jun 2026 03:43:04 GMT

Part Number: AM625-Q1
Other Parts Discussed in Thread: SYSCONFIG

I have a question that I'd like to ask you for advice

One: I can print garbled characters in CCS using the vprintf_ function, but cannot print in the serial port tool as shown in the figure in Attachment 1.

Two: DebugP_log debug cannot be accessed and there is no print either. As shown in Figure 2 of Attachment.

The current UART configuration is as follows :

/* UART Driver Parameters */

UART_Params gUartParams[CONFIG_UART_NUM_INSTANCES] =

{

.baudRate = 115200,

.dataLength = UART_LEN_8,

.stopBits = UART_STOPBITS_1,

.parityType = UART_PARITY_NONE,

.readMode = UART_TRANSFER_MODE_BLOCKING,

.readReturnMode = UART_READ_RETURN_MODE_FULL,

.writeMode = UART_TRANSFER_MODE_BLOCKING,

.readCallbackFxn = NULL,

.writeCallbackFxn = NULL,

.hwFlowControl = FALSE,

.hwFlowControlThr = UART_RXTRIGLVL_16,

.transferMode = UART_CONFIG_MODE_POLLED,

.skipIntrReg = FALSE,

.uartDmaIndex = -1,

.intrNum = 219U,

.intrPriority = 4U,

.operMode = UART_OPER_MODE_16X,

.rxTrigLvl = UART_RXTRIGLVL_8,

.txTrigLvl = UART_TXTRIGLVL_32,

.rxEvtNum = 0U,

.txEvtNum = 0U,

};

I would like to ask: 1. Why doesn't DebugP_log take effect? 2. How to print normally?

TCAN1463EVM: Fault Analysis

xiaochuan wang xiaochaun — Wed, 10 Jun 2026 01:01:13 GMT

Part Number: TCAN1463EVM

The device does not power on, the CAN bus is not self-activated, and there is no voltage on the INH pin

MSPM0G3507: Configuring Write Protection on MSPM0G3507

Reshma Roohi — Mon, 08 Jun 2026 12:33:13 GMT

Part Number: MSPM0G3507
Other Parts Discussed in Thread: UNIFLASH

Hello TI Support Team,

My firmware consists of a bootloader and an application. Currently, for evaluation purposes, I am protecting only the application region (starting at 0xA000). My long-term goal is to protect both the bootloader and application regions.

Could you please clarify whether the MSPM0 security password can be used by the bootloader to access or launch a protected application, or if the password mechanism is intended only for SWD/debug recovery operations such as Mass Erase and Factory Reset?

I have listed below the steps I followed for the security configuration.

Security Configuration

The following security features are enabled:

Static Write Protection
Password-Protected Mass Erase
Factory Reset

The static write protection configuration used is:

FLASHSWP0 = 0xFFFFFFFF

FLASHSWP1 = 0xFFFF001F

Based on my understanding of the MSPM0 flash protection mechanism:

FLASHSWP0 controls protection for the lower 32 KB of flash, with one bit representing one 1 KB sector.
FLASHSWP1 controls protection from 32 KB to 128 KB, with one bit representing eight 1 KB sectors (8 KB).
A value of 0 enables write protection.

Since FLASHSWP0 is all 1s, the first 32 KB remains unprotected.

For FLASHSWP1, bits [15:4] are configured as 0, resulting in protection being applied from 32 KB through 128 KB. Since my application starts at 0xA000 (40 KB), the application code resides within the protected region.

Testing Performed

I performed the following tests:

Programmed the firmware with the above security configuration.
Configured the SWD password in the CCS target configuration.
Verified that the device could be programmed and debugged.
Used UniFlash to execute a password-protected Mass Erase operation.
Observed the following sequence in the logs:
Initiating Device Mass Erase
Attempting SEC_AP connection
Command Sent
SEC_AP Disconnect

SEC_AP Reconnect

After the reconnect sequence, UniFlash reported a failure while accessing SEC_AP registers.
Following this, I observed:
- Flash loader failures in CCS
- DAP connection errors
- Inability to perform Factory Reset
- Repeated SWD communication errors
The device was eventually recovered by using the NRST line and reconnecting through the debugger.

Request for Clarification

Could you please clarify:

Whether the static write protection configuration described above is correct for protecting the application region beginning at 0xA000.
Whether the observed behavior after executing password-protected Mass Erase is expected.
Whether password-protected Mass Erase affects NONMAIN memory and security configuration regions.
Whether the SEC_AP access failure after the erase operation is a known behavior.
Whether any additional CCS or UniFlash configuration is required when validating password-protected Mass Erase and Factory Reset functionality.

I have attached screenshots of my security configuration and debugger/tool configuration for reference. Unfortunately, I do not have screenshots of the error dialogs and logs that were observed during testing, but I have summarized the sequence of events and messages above as accurately as possible.

Thank you for your support.

AFE7901: Missing controls for NCO switching in C API

Vytautas Buitvydas — Thu, 04 Jun 2026 09:07:16 GMT

Part Number: AFE7901
Other Parts Discussed in Thread: AFE7920

Hello,

I am currently trying to implement CAFE_V2p9 library into custom software solution using the provided C API and have encountered a problem with NCO controls. The TI provided data sheet - sbas956c_AFE79xx_full-06-2020.pdf in section 9.3.2.6.3 states that it is possible to switch NCOs using either SPI commands or dedicated remap-able GPIO pins. In my particular case, SPI commands are the prefered way of controlling the NCO switching behavior.

The problem is that I am unable to find any C API commands that would enable me to control NCO switching behavior. I examined all API commands and also checked the TI provided AFE7920 TRM manual for any registers that would allow for direct control and unfortunately was not able to find anything useful.

Is it even possible to control NCO switching through SPI commands? If so, could you provide any kind of support?

DLP473TE: Is DMD Park command for DLPC84XX available?

collin liao — Thu, 04 Jun 2026 05:49:57 GMT

Part Number: DLP473TE

Hi,

I am developing a controller for DLPC84XX. I am looking for the DMD Park command in the software programming guide (link) but I can't find it. Do you have the document explaing how to do that?

AFE7901: AFE7901: Surface-level AFE79XX C API documentation

Vytautas Buitvydas — Tue, 02 Jun 2026 11:17:18 GMT

Part Number: AFE7901

Hello,

Currently, I am trying to implement the control and configuration functions of CAFE79XX_V2p5 library using provided C API, but have found that the provided documentation - afe79xxCLibsDocumentation.chm covers only surface-level description of the provided C API functions. Documentation does not provide any guide on how or when to use them or what results to expect after the execution.

For example, function updateTxNco(...) does not provide any information about the automatic Carrier Aggreagtion Spacing calculation that is perfomed after the frequency is set. Instead it says that it allows to update NCO frequency for a single band (very ambiguous: band0 or band1???).

Another example, function updateTxNcoMultiNcoMode(...) does not provide a slightest hint on what is a Multi NCO mode and how to enable it, but instead lists a possible list of 16 controllable NCOs, which according to technical data sheets, do not even exist in a single RX/TX chain block diagram.

Documentation assumes that the programmer already has in-depth knowledge about chip, which is frustrating.

Is there an updated version of C API documentation that has a complete guide, which can better explain the use of functions, without the need of inspecting the actual library source code?

TMDSCNCD263P-SIP: AM263Px: Unable to Read JEDEC ID Correctly in OSPI Octal DDR (8D-8D-8D) Mode

ARAVIND E — Tue, 02 Jun 2026 09:26:10 GMT

Part Number: TMDSCNCD263P-SIP
Other Parts Discussed in Thread: SYSCONFIG

Hi Team,

I am working on AM263Px with an OSPI NOR Flash device and trying to communicate in Octal DDR (8D-8D-8D) mode.

The controller is configured as follows:

- OSPI_setProtocol(ospiHandle, 0x01080808U)
- OSPI_enableDDR(ospiHandle)
- OSPI_setDualOpCodeMode(ospiHandle)
- OSPI_setCmdExtType(ospiHandle, OSPI_CMD_EXT_TYPE_REPEAT)

I am using OSPI_readCmd() with command 0x9F to read the flash JEDEC ID.

Code snippet:

OSPI_ReadCmdParams_init(&readcmdparameter);
readcmdparameter.cmd = 0x9FU;
readcmdparameter.cmdAddr = OSPI_CMD_INVALID_ADDR;
readcmdparameter.numAddrBytes = 0U;
readcmdparameter.rxDataBuf = buffer;
readcmdparameter.rxDataLen = 3U;
readcmdparameter.dummyBits = 8U;

OSPI_readCmd(ospiHandle, &readcmdparameter);

Console Output:

10101
1080808

-------------OCTAL DDR--------------

Manufacturer ID: 0x04
Device ID: 0x04
Device ID: 0x04

Observations:
- The protocol changes successfully from 0x10101 to 0x1080808.
- OSPI_readCmd() completes without error.
- However, the returned ID bytes are 0x04 0x04 0x04 instead of the expected JEDEC ID.

Could you please clarify:
1. Is command 0x9F supported in Octal DDR mode for this flash device?
2. Is the command extension configuration (REPEAT mode) correct?
3. What is the required number of dummy cycles for JEDEC ID read in 8D-8D-8D mode?
4. Is there a recommended example for reading JEDEC ID using OSPI_readCmd() in Octal DDR mode on AM263Px?

MCU+ SDK Version: 26.00.00.06
Flash Device: nor flash
Board: AM263Px Control card

Thanks.