API solutions Forum - Recent Threads

TPSM33625FEVM: TI-API: Inventory Subscription Push callback blocked by TI Web Filter (403)

redtea tang — Thu, 01 Oct 2026 06:17:35 GMT

Part Number: TPSM33625FEVM
Other Parts Discussed in Thread: TI-API,

Hello TI API Support,

I am opening this new TI-API topic as advised in my previous E2E exchange.

My TI Store API suite shows “Access approved” (29 September 2026). In the myTI Inventory Subscription API settings, the callback is configured as:
API URL: https://mpnradar.com/api/ti/inventory/callback
Data format: JSON
Authentication: Basic (credentials are configured but are not included in this public post).

When testing with POST transact.ti.com/.../test, webhook delivery fails. The test result includes an HTML “Restricted Site” page titled “Texas Instruments - Web Filter”, with /mwg-internal/ references, and reports a callback 403. Our application has not recorded an accepted test callback.

From an external network, mpnradar.com resolves publicly, its HTTPS certificate validates, and TLS 1.2 connects successfully.

Could you please confirm:
1. Is mpnradar.com blocked by TI’s outbound Web Filter or by a callback endpoint review policy?
2. Does this callback URL require explicit review, approval, or allowlisting? If so, what steps and expected review time apply?
3. If the callback hostname differs from the registered myTI customer domain, is that acceptable?
4. Can TI determine whether the test request reached our endpoint and which source IP or policy returned the 403?

The support instructions requested “TI-API” as the part number, but the required part selector does not offer a TI-API entry. I selected TPSM33625FEVM (referenced in the related E2E discussion) only to satisfy the required selector. This is a general TI-API callback-delivery issue, not a device inventory question.

Thank you.

AM263P2: Clarification on eFuse Register Access in HS-SE Mode (AM263Px)

Jayanthi Guruswamy — Mon, 21 Sep 2026 12:16:17 GMT

Part Number: AM263P2

Hello TI Team,

We are reviewing the security architecture for the AM263Px device and would like clarification regarding host-core access to eFuse/OTP registers after the device transitions to High Security - Security Enforced (HS-SE) mode.

We are assuming that TI's foundational security architecture revokes host-core access to certian eFuse registers once the device transitions to HS-SE mode.

Is our understanding correct on Jtag eFuses? or the above statement in general is wrong?

Thanks in advance!

TPSM33625FEVM: TI Inventory Subscription Push API – Callback Blocked by TI Web Filter (403)

Hui He — Sun, 20 Sep 2026 18:26:42 GMT

Part Number: TPSM33625FEVM
Other Parts Discussed in Thread: TI-API

Hello TI API Team,

This is a TI API support request, not a device-specific technical question.
The part number field was populated only because the support form requires a valid TI product.

Previous Customer Support case: CS3591219.

We are integrating the TI Inventory Subscription Push API.

Our callback endpoint is:

https://push.chipharbo.com/api/ti/inventory-webhook

The callback endpoint has already been verified from the public Internet:

- DNS resolves correctly
- HTTPS/TLS certificate is valid
- Port 443 is publicly reachable
- GET /health returns HTTP 200
- POST requests to the callback return HTTP 200
- Basic Authentication has been verified
- The callback returns:
{"status":"accepted"}

Our TI Store API access is also working normally:

- OAuth authentication succeeds
- GET /v2/store/subscriptions/inventory succeeds with HTTP 200
- Active Inventory Subscriptions can be retrieved successfully

However, when calling:

POST transact.ti.com/.../test

the API request itself returns HTTP 200, but the webhook delivery result is:

status: failed
responseCode: 403

The returned response contains:

Restricted Site
Texas Instruments - Web Filter
/mwg-internal/

No webhook request reaches our server when this 403 occurs.

We have also tested with different valid API credentials, and the same callback endpoint is still blocked by the TI Web Filter.

Could the TI API Team please help confirm:

1. Whether push.chipharbo.com is currently blocked by the TI outbound Web Filter.

2. Whether the following callback endpoint requires TI-side review, approval, or allowlisting:

https://push.chipharbo.com/api/ti/inventory-webhook

3. If the endpoint is blocked because of URL reputation, URL category, domain policy, or another TI security policy, what action is required for approval?

4. Whether callback endpoint approval is associated with:
- the callback URL/domain,
- the myTI company account,
- or the API application / Client ID.

5. If the API Client ID / Client Secret is replaced or rotated in the future, whether the same approved callback endpoint can continue to be used without another review.

Our main request is to have this callback endpoint approved for TI Inventory Subscription Push traffic.

We can provide sanitized /inventory/test logs and exact test timestamps privately if required.

Thank you.

LP-EM-CC35X1: CC35XX PSA Crypto: Is a combined ECDSA + ECDH key policy supported?

Vishnu Babu — Fri, 11 Sep 2026 07:33:13 GMT

Part Number: LP-EM-CC35X1
Other Parts Discussed in Thread: SHA-256, SYSCONFIG

Hi TI Team,

I am working with a CC35XX device using SimpleLink Wi-Fi SDK 10.10.01.08 and the PSA Crypto API.

I need to use a single persistent P-256 ECC key pair for two operations:

ECDSA P-256 + SHA-256 signing
ECDH P-256 key agreement

This is based on an existing implementation on another platform where the same PSA key is configured with a primary ECDSA algorithm and ECDH as the enrollment/secondary algorithm.

The key attributes I am using are:

psa_key_attributes_t attributes = PSA_KEY_ATTRIBUTES_INIT;
psa_set_key_type(&attributes, PSA_KEY_TYPE_ECC_KEY_PAIR(PSA_ECC_FAMILY_SECP_R1));
psa_set_key_bits(&attributes, 256);
psa_set_key_usage_flags(&attributes, PSA_KEY_USAGE_SIGN_HASH | PSA_KEY_USAGE_DERIVE);
psa_set_key_algorithm(&attributes, PSA_ALG_ECDSA(PSA_ALG_SHA_256));
psa_set_key_enrollment_algorithm(&attributes, PSA_ALG_ECDH);
psa_set_key_lifetime(&attributes, PSA_KEY_LIFETIME_PERSISTENT);

I have tested both psa_generate_key() and psa_import_key().

1. `psa_import_key()` result

Before importing the key, the attributes are:

Algorithm  = 0x06000609   // PSA_ALG_ECDSA(PSA_ALG_SHA_256)
Algorithm2 = 0x09020000   // PSA_ALG_ECDH
Usage      = 0x00005400   // SIGN_HASH | DERIVE
Lifetime   = 0x00000001   // PSA_KEY_LIFETIME_PERSISTENT

The import succeeds.

However, after retrieving the key attributes using:

psa_get_key_attributes()

I get:

Type       = 0x00007112
Bits       = 256
Usage      = 0x00005400
Algorithm  = 0x06000609
Algorithm2 = 0x06000609
Lifetime   = 0x00000001

So the ECDH enrollment algorithm appears to be changed from:

PSA_ALG_ECDH to:PSA_ALG_ECDSA(PSA_ALG_SHA_256)

during key import/storage.

2. ECDSA operation

Using the imported persistent key:

psa_sign_hash(key_id,
    PSA_ALG_ECDSA(PSA_ALG_SHA_256),
    ...
);

works successfully.

3. ECDH operation using the same key

When I try:

psa_raw_key_agreement(PSA_ALG_ECDH, device_key_id, peer_public_key,
    peer_public_key_length, shared_secret, shared_secret_size, &shared_secret_length);

the operation fails with:

PSA_ERROR_NOT_PERMITTED (-133)

4. Standalone ECDH test

To verify that ECDH itself is supported and working, I created two separate temporary P-256 key pairs with:

psa_set_key_usage_flags(&attributes, PSA_KEY_USAGE_DERIVE);
psa_set_key_algorithm(&attributes, PSA_ALG_ECDH);
psa_set_key_lifetime(&attributes, PSA_KEY_LIFETIME_VOLATILE);

ECDH works successfully in both directions, and both sides produce the same 32-byte shared secret.

Therefore, standalone P-256 ECDH through the CC35XX HSM is working.

My question

Is a single ECC P-256 key with combined ECDSA + ECDH usage supported by the CC35XX PSA Crypto implementation?

Specifically, is the following policy supported?

Key type: ECC P-256 key pair
Usage: PSA_KEY_USAGE_SIGN_HASH | PSA_KEY_USAGE_DERIVE
Primary algorithm: PSA_ALG_ECDSA(PSA_ALG_SHA_256)
Enrollment/secondary algorithm: PSA_ALG_ECDH

If it is supported, could you please advise:

Is there a specific key attribute configuration required for combined ECDSA + ECDH?
Is psa_set_key_enrollment_algorithm() supported for persistent CC35XX keys?
Is there a limitation in the CC35XX HSM/key store that causes alg2 to be replaced by the primary algorithm during psa_generate_key() or psa_import_key()?
Is there a recommended way to configure a single persistent key for both ECDSA signing and ECDH key agreement?
If combined policy is not supported, is the recommended approach to use two separate persistent ECC key pairs—one for ECDSA and one for ECDH?

SysConfig configuration

One additional observation: in my .syscfg project configuration, under:

Crypto Drivers  → TI Security Drivers

I currently have PSA Crypto + KeyStore and RNG added.

I have not explicitly added separate SHA2, ECDSA, ECDH, or AES-GCM driver instances.

My application will require:

SHA-256
TRNG
ECDSA
ECDH
AES-256-GCM

Could the absence of these individual Crypto Driver instances affect PSA Crypto functionality on CC35XX, or are these operations automatically provided through the PSA Crypto/HSM implementation after psa_crypto_init()?

I would appreciate any guidance on the supported combined-key policy and the required SysConfig configuration.

Thanks.

AM62A7-Q1: DLInferer::run() call blocks.

junliang xia — Thu, 10 Sep 2026 02:50:15 GMT

Part Number: AM62A7-Q1

Calling DLInferer::run() requires setting the export TIDL_RT_DDR_STATS=0 variable; otherwise, after normal calls for a period of time, it will block in DLInferer::run().
After setting the export TIDL_RT_DDR_STATS=0 variable and calling DLInferer::run(), if the systemctl restart command is used to restart the service program that calls the DLInferer::run() interface, it will block in DLInferer::run() after 20 to 40 restarts. The resource release issues within the service program have already been investigated, and no abnormal resource release issues have been found.

TMS320F2800156-Q1: Flashdriver

youjun zhang — Wed, 09 Sep 2026 08:43:21 GMT

Part Number: TMS320F2800156-Q1
Other Parts Discussed in Thread: SIMMA-3P-UDS, SIMMA-3P-FLASHBOOTLOADER, C2000WARE

hi expert:

In the UDS requirements, flashdriver.hex (a separate file stored in RAM) is needed to perform flash erase and write operations. Firstly, in BootLoader, can commutation is used to receive flashdriver.hex. After successful reception, the erase and write operation functions are called to update the app.hex. Is there any relevant routine or solution introduction? How to use the flashAPI library file to create a flashdriver

DLPC964: How to check the internal temperature

Shinkichi Kuroiwa — Fri, 04 Sep 2026 09:06:32 GMT

Part Number: DLPC964
Other Parts Discussed in Thread: DLPLCRC964EVM, TMP411

Please explain how to check the internal temperature of the DLPC964.

DLPC964: How to check the internal temperature

Shinkichi Kuroiwa — Fri, 04 Sep 2026 09:06:32 GMT

Part Number: DLPC964

Please explain how to check the internal temperature of the DLPC964.

AM62P: For inquiries regarding DSS sending issues

Q W — Wed, 02 Sep 2026 10:52:21 GMT

Part Number: AM62P

Hello

As shown in the following figure, a CRC check value needs to be added at the end of each frame of the sent video stream, and this value needs to be sent in the HFP. May I ask if our DSS supports this method?If supported, what configurations and operations need to be done

AM2434: Regarding the EtherCAT SubDevice, the processing time for each process is longer than expected.

?? ?? — Tue, 01 Sep 2026 08:39:42 GMT

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

Hello to the development team.

I am developing software for an EtherCAT subdevice using your LP-AM243 board.

We encountered the issue mentioned in the title during the course of development.

Environment

Board: LP-AM243

SDK: ind_comms_sdk_am243x_2026_00_00_06 (Standard) and MCU+SDK mcu_plus_sdk_am243x_12_00_00_26

Usage Example: 401_simple from EtehrCAT_Subdevice_demo

Problem

We are attempting EtherCAT communication using DC synchronization with a cycle time of 250 µs.

Test Case 1:
We confirmed that communication operates normally when the process data size is 14 bytes for input and 18 bytes for output.

Test Case 2:
We confirmed that communication fails (becomes abnormal) when the process data size is 798 bytes for input and 722 bytes for output.

Ideally, we would like to establish communication using a single sub-device with data sizes of up to 1 KB in each direction, as in Test Case 2.

Investigation

To investigate the issue and check task load, we used FreeRTOS hook functions to monitor the task context and measure task execution times. The results were as follows:

Conditions: Cycle time 250 µs, DC synchronization, OP state

Test Case 1:
BEPDItask: Approx. 74 µs
BESync0Task: Approx. 115 µs
Appl_LoopTask: Approx. 35 µs

Test Case 2:
No measurement results available (failed to transition to OP state).

Questions

1. Is it possible to communicate with process data sizes of up to 1 KB (as in Test Case 2) using the desired cycle time and synchronization method?
If so, please provide an estimate of the maximum configurable process data size under these conditions.
2. Regarding the BESync0Task and BEPDItask in Test Case 1, the execution times seem quite long relative to the configured process data size; are these considered reasonable execution times?

Thank you for your assistance.

Kind regards,

TMS320C6748: G722.2 (AMR-WB) Codec for C6x DSP

Uwe Halm — Mon, 31 Aug 2026 13:47:52 GMT

Part Number: TMS320C6748

Does TI provide a library for G722.2 Codec for C674x DSPs?

TMS320F280049C: SCI Bootloader: .TXT file format datasheet

Nibesh Khulal — Mon, 31 Aug 2026 12:40:06 GMT

Part Number: TMS320F280049C
Other Parts Discussed in Thread: LAUNCHXL-F2800157

SCI Bootloader:
FILE: flashapi_ex2_sciKernel.c
FILE: flashapi_ex3_liveFirmwareUpdate.c

Hello, I am looking for help understanding the UART bootloading TXT file format.

I would like to understand the structure and flow of the TXT file format. If you have any documentation, datasheets, or reference materials related to the TXT file format, it would be very helpful for my understanding.

Thank you.

AM62P-Q1: AM62Px: A53 Core 0 Fails to Boot After Running MAIN and MPU PBIST in SBL Stage 2 (MCU+ SDK 10.00.00)

ayyappa T — Fri, 28 Aug 2026 06:07:48 GMT

Part Number: AM62P-Q1

SDK Version: MCU+ SDK 10.00.00

Executing Core: WKUP R5F (SBL OSPI Stage 2)

Hi TI Team,

We are working on implementing Memory Built-In Self-Test (PBIST) in the SBL (OSPI Stage 2) sequence on the AM62Px SoC before loading and executing remote core image binaries.

Implementation Details

We are running PBIST from the WKUP R5F core during SBL OSPI Stage 2.

MCU PBIST instances are handled separately using their respective dedicated APIs (SDL_SBL_PBIST_selfTest).

We ported and integrated the pbist_mpu example logic into SBL Stage 2 to test the MAIN and MPU instances prior to loading the A53 images (bare metal).

Issue Description

When executing PBIST on the MAIN and MPU instances during Stage 2:

PBIST completes (or passes), but A53 Core 0 fails to boot / execute afterwards.

Even after attempting the recommended hardware power-down and restoration sequences (via Sciclient / PSC force updates) to restore default device states, the A53 core remains stuck or deadlocked.

If we disable the MAIN and MPU PBIST steps in SBL Stage 2, the A53 core boots up normally without issues.
Questions:

Are there specific isolated power-domain reset, clock-gating, or TISCI sequence steps required to completely restore the MPU (Compute Cluster) and MAIN interconnects to a clean operational state after PBIST completes?

Is running MPU PBIST directly from SBL Stage 2 (WKUP R5) supported without requiring a full SoC warm reset afterwards?

Does TI provide a specific reference sequence or example for running destructive MPU/MAIN PBIST within SBL prior to handing off execution to A53?

Provide us details regarding the POST test how can we trigger it from the HS_FS devices and How can we check the result from the SBL itself.

Any guidance on missing clean-up or power restoration steps would be greatly appreciated.

Thanks and regards.

MSP430FR6045: Countermeasures for Ultrasonic Sensor Degradation in Ultrasonic Water Meters

Kenichi Maruyama — Fri, 21 Aug 2026 05:19:24 GMT

Part Number: MSP430FR6045

I hope this email finds you well. I would like to consult you regarding an accelerated test we conducted on the ultrasonic sensor.

Under normal operating conditions, the sensor is expected to be pulsed approximately 300 million times over the 10-year guaranteed service life. In our accelerated test, we shortened the pulse interval (period) to 1/100 of the actual operating interval, completing all 300 million pulses within a few months. As a result, we detected a non-negligible change in calibration accuracy (measurement offset/drift).

Regarding this, we would appreciate your guidance on the following two points:

1. Is it technically plausible that drastically shortening the pulse interval in an accelerated test could produce a different mechanism of calibration drift than what would occur under actual field conditions (i.e., pulsing naturally over 10 years)?

2. If such an effect (specific to the accelerated test conditions) can indeed occur, what countermeasures should be implemented on the microcontroller side (signal processing / correction logic)?

For reference, we understand the possible causes of sensor degradation as follows:

[Degradation that could inherently occur under actual field use (dependent on pulse count)]
- Fatigue of the piezoelectric element (transducer), causing changes in resonant frequency, sensitivity, and sound pressure level
- Creep or delamination of the diaphragm or adhesive layer
- Metal fatigue at electrodes or lead wires, leading to degraded connections

[Possible artifacts specific to the accelerated test (due to the shortened cycle time)]
- Because the shortened pulse interval does not allow sufficient time for heat dissipation, the element may operate under a continuously elevated temperature state. This could cause reversible or irreversible changes in piezoelectric properties (e.g., dielectric constant, mechanical Q factor).

Given the above distinction, we would greatly appreciate your opinion on whether the calibration drift detected in the accelerated test represents an intrinsic degradation that would also occur under actual field use, or whether it is a phenomenon specific to the test conditions.

Thank you very much for your time, and we look forward to your response.

Best regards,

LMK04832-SP: Technical Inquiry: Comparison between SEP and EP variants for LMK04832 and LMX2694

Lars Jackson — Thu, 20 Aug 2026 13:57:18 GMT

Part Number: LMK04832-SP
Other Parts Discussed in Thread: LMK04832-SEP, LMX2694-SEP, LMX2694-EP

Dear Texas Instruments Support Team,

I am writing to request technical clarification regarding the similarities and differences between the Space Enhanced Plastic (SEP) and Enhanced Plastic (EP) product variants for two specific components we are currently evaluating.

Specifically, we are looking at the following parts:

LMK04832-SEP vs. LMK04832-EP
LMX2694-SEP vs. LMX2694-EP

To help us determine the appropriate component for our application requirements, could you please provide detailed information on the following:

Manufacturing Location (Foundry and Assembly): Are the SEP and EP variants fabricated in the exact same foundry? Additionally, are they assembled and tested at the same facilities, or are there different supply chains/locations used for the SEP line versus the EP line? We know that there are two potential fabrication location that TI uses for these devices, but it is important to us to know if the components are fabricated at the same foundry or not.
Die and Silicon: Do the SEP and EP versions of these parts share the exact same silicon die and revision?
Packaging and Materials: Are there any physical differences in the packaging, such as the mold compound, bond wires, or lead-frame finish?
Screening and Qualification: What are the specific differences in manufacturing flows, lot acceptance testing, and baseline qualifications between the SEP and EP variants?
Radiation Tolerance: We understand SEP generally includes radiation lot acceptance or characterization. Could you provide the Single Event Effects (SEE) and Total Ionizing Dose (TID) data for the SEP parts? Furthermore, since they may share the same die, do the EP parts share the same baseline radiation performance, or are they entirely uncharacterized and lacking lot-to-lot traceability for radiation?
Documentation: Are there any TI application notes, reliability reports, or side-by-side comparison matrices available for these specific part numbers?

Thank you in advance for your time and support.

AM62P: [AM62P-TISDK-Baremetal ] SDL tests covers PBIST , and TI provided an example, does it need to be called when all cores are in reset mode?

shriya kulkarni — Thu, 20 Aug 2026 13:08:25 GMT

Part Number: AM62P

Hi Team,

I need clarity on SDL tests to be called during which boot up sequence. SDL tests consists of PBIST , can be it called later once all cores are up and running ? Do we need to follow the reset sequence here. Please provide me expected steps to trigger SDL tests .

If there is flowchart/document please share it.

Thanks,

Shriya

AM62P: the EMC init position

Q W — Thu, 20 Aug 2026 05:30:14 GMT

Part Number: AM62P

hello,

Currently, emmc is initialized within the task in the wkup R5 core. Can we move it to complete the initialization before the task starts?

TPS628301: What is the Country of Diffusion(COD) for TPS628301ADRLR?

語庭劉 — Tue, 18 Aug 2026 06:44:00 GMT

Part Number: TPS628301

What is the Country of Diffusion(COD) for TPS628301ADRLR?

AM6422: AM6422: Configuring Firewall in Board Configuration

William Durocher — Mon, 17 Aug 2026 12:20:00 GMT

Part Number: AM6422
Other Parts Discussed in Thread: SYSCONFIG

Is it possible to configure the firewall through the board configuration.

I have looked at the possible outputs of SysConfig both in K3 respart and SDK and neither generate the expected "sciclient_defaultBoardcfg_rm" file.

From K3 respart I get the file "Am64x_firewall_data.c"

From SDK the firewall regions are in te file "ti_drivers_config.c"

Must firewalls be configured exclusively through TISCI messages or is there a path to configure them thoug a board config blob.

Note that I have tried with SDK 12.0.0.27 and both Sysconfig 1.26.0 and 1.28.0

LMR60440: LMR60440 SW Pin Transient Voltage Allowance

RAITA HIGASHITANI — Mon, 17 Aug 2026 06:37:10 GMT

Part Number: LMR60440
Other Parts Discussed in Thread: LMR60410-Q1,

Hello TI Team,

We have a question regarding the SW pin absolute maximum rating of LMR60440.

In the LMR60410-Q1 datasheet, the following note is described:

"Do not externally drive the SW pin. A voltage of 5V below PGND and peak voltage not exceeding 42V for less than 20ns is allowed during switching transitions."

For LMR60440, the Absolute Maximum Ratings specify the SW pin rating as:

"SW to PGND: -0.3V to VIN + 0.3V"

Our customer observed a short-duration undershoot and overshoot on the SW pin during normal switching operation.

Measured conditions:

VIN = 24.2V
SW peak = 26.7V
SW minimum = -3.0V
Duration of overshoot/undershoot ≈ 5ns

We would like to confirm the following:

Does the same transient allowance described for LMR60410-Q1 apply to LMR60440?
Is a transient condition of approximately -3V to 26.7V for about 5ns considered acceptable during switching transitions for LMR60440?
Are there any reliability concerns associated with this level of SW-node ringing?

We appreciate your guidance.

Best regards,

Raita Higashitani

MSP430FR6045: Inquiries Regarding the Terms of Use for Driver Libraries and APIs Related to Development and Publication on GitHub

Kenichi Maruyama — Wed, 05 Aug 2026 01:30:54 GMT

Part Number: MSP430FR6045

We are considering developing an embedded system using the MSP430FR6045 on GitHub.
In this regard, we would appreciate it if you could advise us on any points we should be aware of when using the driver libraries and various APIs provided by your company, such as whether they can be published on GitHub and any licensing restrictions.
Additionally, we would be grateful if you could let us know of any other considerations we should keep in mind as we proceed with development and operation.

AM263P4-Q1: CPTS: `ENET_TIMESYNC_IOCTL_ADJUST_TIMESTAMP` applies only 1/(tsAddVal+1) of the requested frequency correction

Kevin DeVries — Tue, 04 Aug 2026 19:06:59 GMT

Part Number: AM263P4-Q1

**Product:** MCU_PLUS_SDK_AM263Px
**SDK version:** 26.00.00.06
**Device:** AM263P4-Q1 (ZCZ-C package), Cortex-R5F, FreeRTOS
**Component:** `networking/enet` — CPSW CPTS (`cpsw_cpts_ioctl.c`)
**Category:** Functional defect — incorrect scaling
**Severity:** High — silently breaks any PTP clock servo built on this ioctl; the
loop diverges rather than converging

---

## Summary

`ENET_TIMESYNC_IOCTL_ADJUST_TIMESTAMP` under-applies the requested frequency
adjustment by a factor of **(`tsAddVal` + 1)**, which is the CPTS reference-clock
tick in nanoseconds. On AM263Px with the standard 200 MHz CPTS reference the tick
is 5 ns, so **only 1/5 of the requested correction is realised**.

The driver already knows about this scaling and applies it correctly to the
GENF/ESTF outputs a few lines earlier — complete with an explanatory comment —
but omits it for the main `TS_PPM` timestamp adjustment. The two branches
disagree with each other within the same function.

Consequence: a PI clock servo that requests the correct rate correction observes
only 20% of it, concludes the correction was insufficient, and demands more. The
control loop winds up and **diverges**. Because the direction of correction is
right and only the magnitude is wrong, the failure closely mimics a sign error,
which sends debugging in the wrong direction.

## Root cause

In `CpswCpts_ioctl_handler_ENET_TIMESYNC_IOCTL_ADJUST_TIMESTAMP()`,
`source/networking/enet/core/src/mod/cpsw_cpts_ioctl.c:286-319`:

```c
adjVal = (uint64_t)tsAdj->intervalInNsecs / adjOffset; /* line 286 */
if (adjVal <= (uint64_t)CPSW_CPTS_PPM_MIN_VAL) { ... }

tsPpmValHi = (uint32_t)(adjVal >> 32U); /* line 294 */
tsPpmValLo = (uint32_t)(adjVal & 0xFFFFFFFFU); /* line 295 */

if (estfIdxMask != 0U)
{
/* GenF/ESTFn PPM will do correction using cpts refclk tick which is
* (cpts->ts_add_val + 1) ns, so GenF/ESTFn length PPM adj period
* need to be corrected.
*/
estfAdjVal = adjVal * (hCpts->tsAddVal + 1U); /* line 303 <-- scaled */
...
}

if (genfIdxMask != 0U)
{
/* ...same comment... */
genfAdjVal = adjVal * (hCpts->tsAddVal + 1); /* line 314 <-- scaled */
...
}

CSL_CPTS_setTSPpm(regs, tsPpmValLo, tsPpmValHi, ppmDir); /* line 319 <-- NOT scaled */
```

The comment at lines 299-302 states the reason correctly: PPM correction operates
on CPTS reference-clock ticks of `(ts_add_val + 1)` ns. That reasoning applies
equally to `TS_PPM`, which is driven by the same reference clock, but the scaling
is never applied to `tsPpmValLo`/`tsPpmValHi`.

`CSL_CPTS_setTSPpm()` (`hw_include/cpts/csl_cpts.c:301-318`) is a thin register
write and performs no compensation of its own, so the unscaled value reaches the
hardware directly.

`tsAddVal` is assigned from the syscfg reference-clock selection in
`core/src/mod/cpsw_cpts.c:359`:

```c
hCpts->tsAddVal = cptsCfg->cptsRftClkFreq;
```

and the enum values in `core/include/mod/cpsw_cpts.h:238-263` are the add values
themselves (`CPSW_CPTS_RFTCLK_FREQ_200MHZ = 4U`), giving a 5 ns tick at 200 MHz.

### Derivation

`TS_PPM` adds one nanosecond every `adjVal` reference-clock cycles. Each cycle
advances the timestamp by `(tsAddVal + 1)` ns. So the realised fractional rate is

```
rate = 1 ns / (adjVal * (tsAddVal + 1) ns) = 1 / (adjVal * 5) [200 MHz]
```

With `adjVal = intervalInNsecs / |adjValInNsecs|` = `1e9 / X`, the realised
correction in ppb is

```
R = 1e9 / (5 * 1e9 / X) = X / 5
```

Hence passing `X = adjValInNsecs` yields `X/5` ppb rather than `X` ppb. To realise
`R` ppb the caller must pass `X = 5R`.

## Why this likely went unnoticed

The error factor is `(tsAddVal + 1)`. For
`CPSW_CPTS_RFTCLK_FREQ_1000MHZ = 0U`, `tsAddVal` is 0 and the factor is **1** —
the bug is completely invisible at a 1 GHz CPTS reference clock. It only appears
on devices or configurations using a slower reference:

| `cptsRftClkFreq` | `tsAddVal` | tick | error factor |
|---|---|---|---|
| 1000 MHz | 0 | 1 ns | 1.0 (no error) |
| 500 MHz | 1 | 2 ns | 2.0 |
| 250 MHz | 3 | 4 ns | 4.0 |
| 200 MHz | 4 | 5 ns | 5.0 |
| 125 MHz | 7 | 8 ns | 8.0 |

AM263Px syscfg generates `CPSW_CPTS_RFTCLK_FREQ_200MHZ` by default, so every AM263Px
application built from the default configuration hits the 5× error.

## Steps to reproduce

1. Configure CPSW with CPTS at the syscfg default
(`cptsCfg.cptsRftClkFreq = CPSW_CPTS_RFTCLK_FREQ_200MHZ`).
2. Request a known frequency correction — e.g. 28642 ppb:

```c
Enet_IoctlPrms prms;
EnetTimeSync_TimestampAdj tsAdj = {
.adjValInNsecs = 28642, /* intent: +28642 ppb */
.intervalInNsecs = 1000000000U /* over 1 s */
};
int32_t status;
ENET_IOCTL_SET_IN_ARGS(&prms, &tsAdj);
ENET_IOCTL(hEnet, coreId, ENET_TIMESYNC_IOCTL_ADJUST_TIMESTAMP, &prms, status);
```

3. Measure the actual rate change of the CPTS timebase against an external
reference (we used PTP Sync/Follow_Up timestamps from a `ptp4l` master at a
1 s interval, differencing the offset error across successive cycles).

### Observed

Requesting 28642 ppb moved the clock by **5728 ppb** — a ratio of 0.1999, i.e.
exactly 1/5.

Fitting our measured data across four successive servo cycles to
`delta = drift + G · ppb` gave **G = 0.20** and a free-running oscillator drift of
−34798 ppb.

### Expected

Requesting 28642 ppb should move the clock by approximately 28642 ppb
(G = 1.0), subject to the `TS_PPM` register's quantization.

### Confirmation of the diagnosis

After applying the ×5 workaround below, the servo converged and settled at a
steady-state trim of **34605–35016 ppb** — matching the −34798 ppb drift
independently derived from the *pre-fix* diverging data to within 0.6%. This
cross-check confirms both the factor and that no other scaling error is present.

## Workaround

Pre-scale the requested ppb by the CPTS tick in the application:

```c
#define CPTS_TICK_NS 5 /* (tsAddVal + 1) for CPSW_CPTS_RFTCLK_FREQ_200MHZ */

static int32_t cpts_adjust_freq(int32_t ppb)
{
Enet_IoctlPrms prms;
EnetTimeSync_TimestampAdj tsAdj = {
.adjValInNsecs = ppb * CPTS_TICK_NS,
.intervalInNsecs = 1000000000U
};
int32_t status;
ENET_IOCTL_SET_IN_ARGS(&prms, &tsAdj);
ENET_IOCTL(hEnet, coreId,
ENET_TIMESYNC_IOCTL_ADJUST_TIMESTAMP, &prms, status);
return status;
}
```

This is unattractive because it hard-codes an SoC- and syscfg-dependent constant
into application code, and it will over-correct by 5× if the driver is ever
fixed. A fix in the driver is strongly preferred.

Result with the workaround in place, on a PTP E2E slave at a 1 s Sync interval:
locks within 3 Sync intervals and holds offset inside ±150 ns.

## Related issues in the same ioctl

**1. `adjValInNsecs == 0` clears all accumulated correction.**
At line 251, a zero adjustment value is treated as "disable frequency correction
entirely" — `CSL_CPTS_setTSPpm(regs, 0U, 0U, ...)` plus clearing every active
GENF/ESTF:

```c
if (tsAdj->adjValInNsecs == 0)
{
CSL_CPTS_setTSPpm(regs, 0U, 0U, CSL_CPTS_TS_PPM_DIR_INCREASE);
...
}
```

This is a hazard for the ioctl's primary use case. A converged clock servo
naturally computes a zero correction once its error reaches zero, and the
intuitive reading of "adjust by 0" is "make no change" — not "discard the trim
that is currently holding lock." Doing so drops the ~34900 ppb of trim and sends
the clock back into free-run drift. We had to add an explicit guard forcing ±1
to avoid it.

Suggestion: document this clearly, or better, move the "disable correction"
semantics to an explicit mode (`ENET_TIMESYNC_ADJMODE_DISABLE` already exists in
this API for GENF/ESTF) and treat 0 as a no-op.

**2. `adjValInNsecs` has no documented units or semantics.**
`EnetTimeSync_TimestampAdj` in `core/include/core/enet_mod_timesync.h:261-268`
documents the field only as *"Adjustment value for timestamp"*:

```c
typedef struct EnetTimeSync_TimestampAdj_s
{
/*! Adjustment value for timestamp */
int32_t adjValInNsecs;

/*! Interval to apply the adjustment */
uint32_t intervalInNsecs;
} EnetTimeSync_TimestampAdj;
```

Nothing states that the pair expresses a *rate* (add `adjValInNsecs` ns per
`intervalInNsecs` ns), that the resulting ratio is what is programmed, or what
the valid range is. We inferred the intended contract from the implementation.
Given the scaling defect above, clear documentation of the intended units would
also make the discrepancy self-evident.

**3. Maximum correction is silently capped at ~195 ppm.**
`adjVal` is floored at `CPSW_CPTS_PPM_MIN_VAL` (0x400 = 1024) at lines 287-292.
Since `adjVal = 1e9 / X`, that floor implies `X <= 976562`, i.e. a maximum
realisable correction of about **195 ppm** (with the ×5 workaround applied).
Requests beyond that are clamped with only an `ENETTRACE_WARN`, which is compiled
out in release builds — so an application asking for more correction than the
hardware can deliver receives `ENET_SOK` and no indication of the clamp. Worth
documenting the limit in the header.

**4. `SET_GENF` / `SET_ESTF` disagree with `ADJUST_TIMESTAMP` on the same scaling.**
`CpswCpts_calcPpmVal()` (line 1074) computes `adjVal` for the
`CPSW_CPTS_IOCTL_SET_GENF` and `CPSW_CPTS_IOCTL_SET_ESTF` handlers (lines 620 and
694) and passes it to `CSL_CPTS_setupGENFn`/`setupESTFn` **without** the
`(tsAddVal + 1)` scaling that `ADJUST_TIMESTAMP` applies to those same outputs at
lines 303 and 314.

By the driver's own reasoning in the comment at lines 299-302, one of these two
paths must be wrong. We have not exercised GENF/ESTF and are not asserting which
— but the inconsistency is worth auditing alongside the primary fix, since a
correction to `TS_PPM` should probably be accompanied by a consistent convention
across all three PPM consumers.

## Suggested fix

Apply the same tick scaling to `TS_PPM` that the function already applies to
GENF/ESTF:

```c
adjVal = (uint64_t)tsAdj->intervalInNsecs / adjOffset;

/* TS_PPM adds 1 ns every adjVal reference-clock cycles, and each cycle
* advances the timestamp by (tsAddVal + 1) ns, so the adjustment period
* needs the same refclk-tick correction as GENFn/ESTFn below. */
adjVal = adjVal / (hCpts->tsAddVal + 1U);

if (adjVal <= (uint64_t)CPSW_CPTS_PPM_MIN_VAL) { ... }
```

Note this divides where GENF/ESTF multiply: `adjVal` is a *period* in cycles, so
a longer tick means proportionally fewer cycles between 1 ns nudges. The GENF/ESTF
values are derived from `adjVal` for a different register whose units differ,
hence the opposite direction. Please treat the direction here as a suggestion to
verify rather than a validated patch — we corrected this in application code, not
in the driver, so we have not tested a driver-side change.

**Compatibility caveat:** this is a behavioural change. Applications that already
compensate for the defect (as ours does) would over-correct by `(tsAddVal + 1)`
once fixed. Worth a prominent release-note entry, and possibly worth confirming
whether any TI-supplied PTP stack for other devices carries a matching
compensation that would also need removing.

## Environment

| | |
|---|---|
| SDK | MCU_PLUS_SDK_AM263Px 26.00.00.06 |
| Device | AM263P4-Q1, ZCZ-C |
| Core | R5FSS0-0, FreeRTOS |
| Compiler | ti_cgt_arm_llvm 4.0.4.LTS |
| CPTS reference clock | `CPSW_CPTS_RFTCLK_FREQ_200MHZ` (syscfg default) |
| Interface | RGMII1, CPSW MAC port 1 |
| Stack | lwIP (SDK-provided lwipif) |
| PTP profile | IEEE 1588 default, E2E delay mechanism, UDP/IPv4 (Annex D), slave only |
| Master | `ptp4l` on Linux, 1 s Sync interval |
| Switch | Microchip LAN9645 |

AM263P4-Q1: CPSW/CPTS: Annex D (PTP over UDP/IPv4) timestamping silently captures nothing when `commonPortIpCfg` is left zeroed

Kevin DeVries — Tue, 04 Aug 2026 18:50:13 GMT

Part Number: AM263P4-Q1

Note: This was developed with the use of AI, and with myself having only basic knowledge of the SDK code and MCU. It may be the AI did not have all of the information, although there are indications that there are gaps in the documentation - both in code and in supporting HTML pages.

**Product:** MCU_PLUS_SDK_AM263Px
**SDK version:** 26.00.00.06
**Device:** AM263P4-Q1 (ZCZ-C package), Cortex-R5F, FreeRTOS
**Component:** `networking/enet` — CPSW MAC port / CPTS
**Category:** Usability / missing parameter validation / documentation gap
**Severity:** Medium — no data corruption, but the failure is silent and costs significant debug time

---

## Summary

Enabling Annex D (PTP over UDP/IPv4) hardware timestamping via
`CPSW_MACPORT_IOCTL_ENABLE_CPTS_EVENT` appears to succeed (`ENET_SOK`) but produces
**zero CPTS events** unless the caller also populates the nested
`tsEventCfg.commonPortIpCfg` sub-structure.

Because the natural idiom is to `memset()` the input args to zero and then set only
the fields of interest, `commonPortIpCfg` is all-zero in the common case. That
combination programs the hardware frame matcher to reject every PTP frame. The
ioctl still returns success, so the only symptom is that every subsequent
`ENET_TIMESYNC_IOCTL_GET_ETH_RX_TIMESTAMP` /
`ENET_TIMESYNC_IOCTL_GET_ETH_TX_TIMESTAMP` call returns `ENET_ENOTFOUND` (-14).

There is nothing in the API to indicate that `rxAnnexDEn`/`txAnnexDEn` have a
mandatory dependency on `commonPortIpCfg`.

## Why the zeroed case rejects everything

In `CpswMacPort_enableCptsPortEvents()`
(`source/networking/enet/core/src/mod/cpsw_macport_ioctl.c:1740-1761`):

```c
if (tsEventCfg->rxAnnexDEn || tsEventCfg->rxAnnexEEn ||
tsEventCfg->txAnnexDEn || tsEventCfg->txAnnexEEn)
{
...
timeSyncCfg.tsTTLNonzeroEnable = commonPortIpCfg->ttlNonzeroEn;
timeSyncCfg.tsUniEnable = commonPortIpCfg->unicastEn;

if (timeSyncCfg.tsUniEnable == FALSE)
{
timeSyncCfg.ts107Enable = commonPortIpCfg->tsIp107En;
timeSyncCfg.ts129Enable = commonPortIpCfg->tsIp129En;
...
timeSyncCfg.ts319Enable = commonPortIpCfg->tsPort319En;
timeSyncCfg.ts320Enable = commonPortIpCfg->tsPort320En;
}
}
```

Enabling Annex D therefore hands the entire IP/UDP filter configuration to
`commonPortIpCfg`. With that struct zeroed, the resulting `CSL_CPSW_TSCONFIG` has
`tsUniEnable = 0` together with every `ts1xxEnable` and both `ts319Enable` /
`ts320Enable` cleared.

Per the field documentation in
`source/networking/enet/hw_include/cpsw/V5/csl_cpsw.h:986-990`:

```
/** Port Time Sync Unicast IP message enable
1: all IP address valid
0: perform multicast address check, only multicast addresses which are enabled are valid
*/
Uint32 tsUniEnable;
```

So `tsUniEnable = 0` selects multicast address checking, and no multicast address
is enabled — the matcher cannot match anything. Unicast is disabled and every
permitted multicast destination is disabled simultaneously, which is an
unsatisfiable filter. The port's TSCONFIG register is written unconditionally at
line 1804 and the function returns `ENET_SOK`.

## Steps to reproduce

1. Configure CPSW with CPTS enabled (`cptsCfg.hostRxTsEn = true`,
`cptsRftClkFreq = CPSW_CPTS_RFTCLK_FREQ_200MHZ`).
2. Enable timestamping on a MAC port using the zero-then-set idiom:

```c
CpswMacPort_EnableTsEventInArgs tsEventInArgs;
Enet_IoctlPrms prms;
int32_t status;

memset(&tsEventInArgs, 0, sizeof(tsEventInArgs));
tsEventInArgs.macPort = ENET_MAC_PORT_1;
tsEventInArgs.tsEventCfg.rxAnnexDEn = true; /* PTP over UDP/IPv4 */
tsEventInArgs.tsEventCfg.txAnnexDEn = true;
tsEventInArgs.tsEventCfg.txHostTsEn = true;
tsEventInArgs.tsEventCfg.messageType = 0xFFFFU;
tsEventInArgs.tsEventCfg.seqIdOffset = 30;
tsEventInArgs.tsEventCfg.domainOffset = 4;
/* commonPortIpCfg deliberately left as memset zeros */

ENET_IOCTL_SET_IN_ARGS(&prms, &tsEventInArgs);
ENET_IOCTL(hEnet, coreId, CPSW_MACPORT_IOCTL_ENABLE_CPTS_EVENT, &prms, status);
/* status == ENET_SOK */
```

3. Add the PTP multicast MAC `01:00:5E:00:01:81` to the ALE so frames reach the
host, join `224.0.1.129`, and run a PTP master (`ptp4l`) on the link.
4. On receipt of each Sync, query the Rx timestamp:

```c
EnetTimeSync_GetEthTimestampInArgs inArgs = {
.msgType = ENET_TIMESYNC_MESSAGE_SYNC,
.seqId = sync_seq,
.portNum = 1U,
.domain = 0
};
uint64_t ts;
ENET_IOCTL_SET_INOUT_ARGS(&prms, &inArgs, &ts);
ENET_IOCTL(hEnet, coreId, ENET_TIMESYNC_IOCTL_GET_ETH_RX_TIMESTAMP, &prms, status);
```

### Observed

- `CPSW_MACPORT_IOCTL_ENABLE_CPTS_EVENT` returns `ENET_SOK`.
- PTP frames arrive correctly at the host (confirmed by the application parsing
Sync/Follow_Up/Delay_Resp contents), so this is not an ALE or DMA problem.
- **Every** Rx and Tx timestamp lookup returns `ENET_ENOTFOUND` (-14). The CPTS
event pool remains empty; the CPSW misc interrupt fires and `Cpsw_cptsIsr`
runs, but no Ethernet Rx/Tx events are ever queued.

### Expected

Either the ioctl rejects the unsatisfiable filter configuration with
`ENET_EINVALIDPARAMS`, or the documentation states that `commonPortIpCfg` must be
populated whenever Annex D or Annex E is enabled.

## Workaround

Populate `commonPortIpCfg` explicitly. With the following, hardware timestamping
works immediately and correctly:

```c
tsEventInArgs.tsEventCfg.commonPortIpCfg.ttlNonzeroEn = true;
tsEventInArgs.tsEventCfg.commonPortIpCfg.unicastEn = false;
tsEventInArgs.tsEventCfg.commonPortIpCfg.tsPort319En = true;
tsEventInArgs.tsEventCfg.commonPortIpCfg.tsPort320En = true;
tsEventInArgs.tsEventCfg.commonPortIpCfg.tsIp129En = true;
```

Measured result after this change, on a PTP end-to-end slave using CPTS
timestamps for t2/t3: path delay steady at 3180-3390 ns and offset held inside
±150 ns, versus no usable timestamps at all beforehand.

## Additional observations

**1. `messageType` semantics are easy to get wrong.**
The field is documented in `cpsw_macport.h:404` as *"Message type value mask is
only for Annex F (PTP)"*. Two problems:

- The "only for Annex F" qualifier is misleading — line 1736 assigns
`tsMsgTypeEnable` unconditionally, outside both the Annex D/E block and the
Annex F block, so it applies to Annex D as well.
- It is a **bitmask over the 16 PTP message types**, not an enum or a maximum. A
plausible-looking `0x000F` silently covers only message types 0-3, which
includes Sync (0x0) and Delay_Req (0x1) but excludes Follow_Up (0x8) and
Delay_Resp (0x9). `0xFFFFU` is needed for full E2E operation. Naming the field
a mask in the doc comment, or defining a `CPSW_MACPORT_TS_MSGTYPE_ALL` macro,
would help.

**2. Which filter bit is actually decisive is unclear.**
The reference example `EnetApp_setPortTsEventPrms()`
(`core/examples/enet_layer2_multi_channel/V1/multi_channel_dataflow.c:682-711`)
sets `ttlNonzeroEn = true`, `tsPort319En = true`, `tsPort320En = true`,
`unicastEn = false`, but leaves **all** `tsIp1xxEn` fields `false`. Our working
configuration additionally sets `tsIp129En = true`.

We have not isolated whether the UDP port match alone is sufficient (implying the
address and port checks are OR-ed) or whether `tsIp129En` is required (implying
AND). Clarifying the matcher's logic in the header documentation would remove the
guesswork.

Relatedly, `csl_cpsw.h:998-1002` documents `ts129Enable` as IPv4 **224.0.0.129**.
The IEEE 1588 Annex D default multicast group is **224.0.1.129**, and 224.0.0.107
/ 224.0.1.129 are the addresses actually used by PTP. If the register really
matches 224.0.0.129 then the field is not usable for standard PTP; if the
documentation has a typo, it is worth correcting since it directly affects how a
reader configures this filter.

**3. No validation of a self-contradictory filter.**
`CpswMacPort_enableCptsPortEvents()` validates only `seqIdOffset`
(against `CPSW_MACPORT_PTP_SEQID_OFFSET_MIN_VAL`, line 1723). A cheap guard would
catch this class of misconfiguration outright:

```c
/* With unicast disabled, at least one multicast address or UDP port must be
* enabled or the frame matcher can never match. */
if ((tsEventCfg->rxAnnexDEn || tsEventCfg->rxAnnexEEn ||
tsEventCfg->txAnnexDEn || tsEventCfg->txAnnexEEn) &&
!commonPortIpCfg->unicastEn &&
!(commonPortIpCfg->tsIp107En || commonPortIpCfg->tsIp129En ||
commonPortIpCfg->tsIp130En || commonPortIpCfg->tsIp131En ||
commonPortIpCfg->tsIp132En || commonPortIpCfg->tsPort319En ||
commonPortIpCfg->tsPort320En))
{
status = ENET_EINVALIDPARAMS;
}
```

## Suggested resolution

Any one of these would have prevented the debug effort; ideally the first two:

1. **Validate** the unsatisfiable filter combination and return
`ENET_EINVALIDPARAMS` instead of silently programming a matcher that cannot
match.
2. **Document** in `CpswMacPort_TsEventCfg` that `commonPortIpCfg` is mandatory
when any Annex D or Annex E flag is set, and document the matcher's
address-versus-port logic.
3. Clarify that `messageType` is a bitmask and that it applies to Annex D, not
only Annex F. Consider providing an all-types macro.
4. Confirm or correct the `224.0.0.129` vs `224.0.1.129` address in
`csl_cpsw.h`.
5. Consider shipping a PTP-over-UDP (Annex D) example. The only in-tree
references to `rxAnnexDEn` are the two `enet_layer2_multi_channel` examples,
which are L2-oriented; a slave using UDP transport has no reference to follow.

## Environment

| | |
|---|---|
| SDK | MCU_PLUS_SDK_AM263Px 26.00.00.06 |
| Device | AM263P4-Q1, ZCZ-C |
| Core | R5FSS0-0, FreeRTOS |
| Compiler | ti_cgt_arm_llvm 4.0.4.LTS |
| Interface | RGMII1, CPSW MAC port 1 |
| Stack | lwIP (SDK-provided lwipif) |
| PTP profile | IEEE 1588 default, end-to-end delay mechanism, UDP/IPv4 (Annex D), slave only |
| Master | `ptp4l` on Linux, 1 s Sync interval |
| Switch | Microchip LAN9645 |

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
Other Parts Discussed in Thread: DLPC3479

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.

API solutions Forum - Recent Threads

TPSM33625FEVM: TI-API: Inventory Subscription Push callback blocked by TI Web Filter (403)

AM263P2: Clarification on eFuse Register Access in HS-SE Mode (AM263Px)

TPSM33625FEVM: TI Inventory Subscription Push API – Callback Blocked by TI Web Filter (403)

LP-EM-CC35X1: CC35XX PSA Crypto: Is a combined ECDSA + ECDH key policy supported?

1. psa_import_key() result

2. ECDSA operation

3. ECDH operation using the same key

4. Standalone ECDH test

My question

SysConfig configuration

AM62A7-Q1: DLInferer::run() call blocks.

TMS320F2800156-Q1: Flashdriver

DLPC964: How to check the internal temperature

DLPC964: How to check the internal temperature

AM62P: For inquiries regarding DSS sending issues

AM2434: Regarding the EtherCAT SubDevice, the processing time for each process is longer than expected.

Environment

Problem

Investigation

Questions

TMS320C6748: G722.2 (AMR-WB) Codec for C6x DSP

TMS320F280049C: SCI Bootloader: .TXT file format datasheet

AM62P-Q1: AM62Px: A53 Core 0 Fails to Boot After Running MAIN and MPU PBIST in SBL Stage 2 (MCU+ SDK 10.00.00)

MSP430FR6045: Countermeasures for Ultrasonic Sensor Degradation in Ultrasonic Water Meters

LMK04832-SP: Technical Inquiry: Comparison between SEP and EP variants for LMK04832 and LMX2694

AM62P: [AM62P-TISDK-Baremetal ] SDL tests covers PBIST , and TI provided an example, does it need to be called when all cores are in reset mode?

AM62P: the EMC init position

TPS628301: What is the Country of Diffusion(COD) for TPS628301ADRLR?

AM6422: AM6422: Configuring Firewall in Board Configuration

LMR60440: LMR60440 SW Pin Transient Voltage Allowance

MSP430FR6045: Inquiries Regarding the Terms of Use for Driver Libraries and APIs Related to Development and Publication on GitHub

AM263P4-Q1: CPTS: `ENET_TIMESYNC_IOCTL_ADJUST_TIMESTAMP` applies only 1/(tsAddVal+1) of the requested frequency correction

AM263P4-Q1: CPSW/CPTS: Annex D (PTP over UDP/IPv4) timestamping silently captures nothing when `commonPortIpCfg` is left zeroed

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

DLP4710EVM-LC: Recommended initialization sequence for splash pattern projection

1. `psa_import_key()` result