Processors forum - Recent Threads

AM68A: AM68A/J721S2: OD-8920 DETR graph verify failure and 11_00_06_00 compiler segfault

Derrick Edwards — Wed, 24 Jun 2026 02:54:20 GMT

Part Number: AM68A

We are attempting to deploy the official TI Model Zoo OD-8920 DETR ONNX on

AM68A/SK-AM68 with `PROCESSOR-SDK-LINUX-AM68A 11.00.00.08`, staying on the

11.00 release family because newer runtime/image attempts break our known-good

YOLOX fallback.

The official AM68A prebuilt package fails before inference on the board:

```text

VX_ZONE_ERROR: [ TIDL subgraph key_value_states ] Node kernel init failed

VX_ZONE_ERROR: [ TIDL subgraph key_value_states ] Graph verify failed

ERROR: MakeTidlDetectionEngine failed: ORT init: Create state function failed. Return value:-1

```

Board/runtime context:

```text

OS: Arago 2025.01

kernel: 6.12.17-ti-00773-gcdcaeac783e3-dirty

libtivision-apps11.0.0: 11.00.00-r0_edgeai_13.57

libonnxruntime1.15.0: 1.0-r0_edgeai_4.40

ti-tidl: 1.0.0-r0_edgeai_2.180

ti-rtos-firmware: 08.02.00.04-r4.1_edgeai_0.1

```

The ONNX graph originally has four outputs:

```text

4041 [1,100,92]

4053 [1,100,4]

onnx::MatMul_4038 [1,100,256]

key_value_states [1,625,256]

```

We pruned the graph outputs to keep only the detector logits and boxes:

```text

4041 [1,100,92]

4053 [1,100,4]

```

The pruned ONNX passes `onnx.checker.check_model` and a CPU ONNX Runtime smoke

run with `ORT_DISABLE_ALL`.

AM68A/J721S2 compile attempt:

```text

target: SOC=am68a, TIDL_TOOLS_PATH=/home/root/tools/J721S2/tidl_tools

edgeai-tidl-tools tag/commit: 11_00_06_00 / 95ba2c7ec62bbedeb637d7a5c0273fcede21cac9

docker image: edgeai_tidl_tools_x86_ubuntu_22:11_00_06_00

c7x_firmware_version: 11_00_00_00

tensor_bits: 8

calibration_frames: 4

calibration_iterations: 5

graph_optimization_level: ORT_DISABLE_ALL

filter_16bit_hints: true

TIDL import outputs:

Output tensor name - 4041

Output tensor name - 4053

late compiler result:

Successful Memory Allocation

Segmentation fault (core dumped)

compiler_exit_status=1

```

For comparison, the exact same pruned ONNX and compile options complete when

targeting AM68PA/J721E:

```text

target: SOC=am68pa, TIDL_TOOLS_PATH=/home/root/tools/AM68PA/tidl_tools

edgeai-tidl-tools tag/commit: 11_00_06_00 / 95ba2c7ec62bbedeb637d7a5c0273fcede21cac9

c7x_firmware_version: 11_00_00_00

tensor_bits: 8

calibration_frames: 4

calibration_iterations: 5

graph_optimization_level: ORT_DISABLE_ALL

filter_16bit_hints: true

late compiler result:

Successful Memory Allocation

Successful Workload Creation

Successful Memory Allocation

Successful Workload Creation

Successful Memory Allocation

Successful Workload Creation

Subgraph Compiled Successfully

Compilation package complete

process exit status: 0

```

The AM68PA/J721E artifact was used only as target-comparison evidence and was

not deployed to AM68A.

Known-good fallback check after these experiments:

```text

cs-camera-daemon ActiveState=active SubState=running NRestarts=0

YOLOX TIDL inference continues at roughly 10.7-11.6 ms per analytics run

```

## Questions

1. Has TI physically validated the AM68A/8bits OD-8920 package on SK-AM68 or a

J721S2 target running Processor SDK Linux AM68A `11.00.00.08`?

2. Are `onnx::MatMul_4038` and `key_value_states` expected graph outputs for

the AM68A package, or should the graph be pruned to logits and boxes before

TIDL import?

3. What exact compile/provider options were used for a known-good AM68A

OD-8920 artifact?

4. Is a compiler segfault after `Successful Memory Allocation` a known issue for

this model on `SOC=am68a` / J721S2 in `edgeai-tidl-tools 11_00_06_00`?

5. If TI has a passing AM68A OD-8920 package, can you provide the exact SDK

image, TIDL tools tag, C7x firmware/libs version, and random-input validation

command used to verify it?

RE: AM68A: AM68A/J721S2: OD-8920 DETR graph verify failure and 11_00_06_00 compiler segfault

Derrick Edwards — Wed, 24 Jun 2026 19:06:21 GMT

Hello,

We are using TI SK-AM68 with AM68A/J721S2, not a Phytec or Toradex SoM.

The issue is with TI-published AM68A Processor SDK / TIDL tooling and TI Model Zoo OD-8920 artifacts, reproduced on SOC=am68a with edgeai-tidl-tools 11_00_06_00. The same pruned model compiles for SOC=am68pa but the AM68A target compiler segfaults after memory planning.

Given the support-transition FAQ, can you confirm the correct support owner for AM68A Processor SDK / TIDL compiler issues on TI SK-AM68? Should this be handled by TI, a local TI contact, Phytec, Toradex, or another TI software partner?

AM62L: AM62L: Codesys with SPI

jiannan zhang — Wed, 24 Jun 2026 09:31:21 GMT

Part Number: AM62L

In that post, the issues encountered during standalone SPI testing were addressed by applying a patch, which resulted in stable ioctl execution time, a jitter of approximately 300 µs, and low CPU usage. Now, the SPI test program has been integrated into CODESYS as a child thread to emulate the actual usage scenario. The SPI test program is reconfigured to execute at a 1 ms period, and spi_mcu_output_test() transmits 200 bytes of data per cycle. Core 1 is dedicated solely to EtherCAT, running a 1 ms cycle with 4 axes, and the program includes only MC_Power and MC_MoveVelocity. All other programs are executed on Core 0.

When the SPI test thread is not present, Core 0 usage is 20 %–45 %, Core 1 usage is 36 %, and the EtherCAT task jitter is approximately 80 µs.

When the SPI test thread is present, Core 0 usage rises to 85 %, Core 1 usage to 45 %, the EtherCAT task jitter increases to about 260 µs, and the SPI test thread jitter reaches as high as 4 ms.

When the SPI test thread is present but EtherCAT is removed, Core 0 usage drops to 66 %, Core 1 usage to 2 %, and the SPI test thread jitter is 400 µs.

The CPU usage statistics reported by htop and CODESYS are in close agreement, and the kernel has been built with CONFIG_VIRT_CPU_ACCOUNTING_GEN enabled. After the program has run stably, the jitter statistics are manually cleared.

In summary, it can be observed that SPI and EtherCAT interfere with each other, even though they are not assigned to the same core, and that CPU usage is excessively high. Please assist in analysing the underlying issues.

RE: AM62L: AM62L: Codesys with SPI

Daolin Qiu — Wed, 24 Jun 2026 18:44:02 GMT

Hello,

May I ask how was the SPI test program was integrated into CODESYS as a child thread? Any details on steps taken to perform this integration? What is unclear to me is that my understanding is that once codesyscontrol starts in Linux, the list of child threads cannot be added to or removed as it is written in the CODESYS source code, which is not available for users (both commericial and developmental).

It was mentioned that SPI test program was integrated as a child thread to emulate the actual usage scenario. What usage scenario is it meant to emulate and is the final goal/deployment to have this SPI program integrated or is it simply meant to simulate the scenario you are describing?

Can you also describe what the purpose of the SPI test program is and what exactly is the SPI test program doing. Does the function the SPI program performs have any dependencies on EtherCAT communication? If so, please describe how the SPI program works.

-Daolin

RE: J722SXH01EVM: J722S EVM: Audio sampling-rate incorrect

Jared McArthur — Wed, 24 Jun 2026 18:35:01 GMT

Hi Somnath Mukherjee,

I've attached the output of k3conf while I am playing the 1kHz tone.

$ aplay 1khz-sine-48khz-sample.wav &
$ k3conf dump clock > clock.log

e2e.ti.com/.../clock.log

Best,
Jared

J722SXH01EVM: J722S EVM: Audio sampling-rate incorrect

Aparna Dutta — Fri, 22 May 2026 08:01:20 GMT

Part Number: J722SXH01EVM

We are using the J722S EVM with the linux SDK version 11.01. For our application, we want to receive audio through the 3.5 mm audio jack.
For basic interface testing we are trying to run aplay and arecord to playback / record some wav files. Here we observe these issues:
1. On playing back a wav file using aplay, the playback duration is much longer than the actual wav file duration and so the pitch is lowered. (30 seconds of audio plays back for 45 seconds)
2. On trying to record an audio using arecord, the recording takes much more time than specified and on playing back the recorded audio, the pitch is higher (15 seconds worth of audio samples are stored in a wav file of 10 secs duration)

It appears that the clock which controls the sampling-rate is probably not configured correctly. Can you please let us know the root-cause of this and how it can be fixed ?

RE: J722SXH01EVM: J722S EVM: Audio sampling-rate incorrect

Keerthy J — Wed, 24 Jun 2026 18:33:09 GMT

Hello Somnath,

A tool in Linux -> k3conf

software-dl.ti.com/.../devices.html

'k3conf dump clock 190' should give out all the frequency values for J722S_DEV_MCASP0.

This should give clock values.

- Keerthy

AM3352: AM3352 DDR3 SI Simulation Fails After Upgrading from 1Gb to 4Gb Memory (Same PCB Layout)

Daniel Cheng1 — Wed, 24 Jun 2026 13:41:28 GMT

Part Number: AM3352

Hi TI Experts,

I am currently running DDR3 Signal Integrity (SI) simulations for our custom AM3352 design.

Previously, the simulation PASSED when using a 1Gb DDR3 memory chip. However, when I switched the memory model to a 4Gb DDR3 chip, the simulation FAILED (mainly due to timing/eye diagram degradation).

Here are the conditions and details of my setup:

PCB Layout: Exactly the same for both cases (the layout has already been finalized).
IBIS Models: I applied the same driver/ODT impedance settings in the simulation tool for both the 1Gb and 4Gb models.

Since the physical layout cannot be changed, I suspect the failure is related to the internal die characteristics, higher capacitive loading ($C_{comp}$), or package parasitic differences between the 1Gb and 4Gb densities.

Could you please provide some guidance on the following questions?

AM3352 Registers Adjustment: To compensate for the heavier loading of the 4Gb DDR3 chip, what are the recommended adjustments for the AM3352 DDR IO control registers (e.g., DDR_CMDx_IOCTRL, DDR_DATAx_IOCTRL) and EMIF ODT settings? Should I increase the drive strength (lower the $\Omega$ value) to improve the slew rate?
DDR3 Side Optimization: What are the typical ODT ($60\,\Omega$, $40\,\Omega$, or $120\,\Omega$) and Driver Impedance ($34\,\Omega$ or $40\,\Omega$) combinations recommended by TI for a 4Gb DDR3 topology on the Sitara platform?
Simulation Best Practices: Are there any specific parameters regarding the AM335x IBIS model that I need to pay extra attention to when matching with higher-density (4Gb) memories?

Any insights or recommendations on how to tune the software/registers to pass the simulation would be greatly appreciated.

Pass:

Fail:

Thanks and best regards,

Daniel

RE: AM3352: AM3352 DDR3 SI Simulation Fails After Upgrading from 1Gb to 4Gb Memory (Same PCB Layout)

Christopher Roberts — Wed, 24 Jun 2026 18:29:12 GMT

Hello Daniel,

The assigned expert is currently out of office, returning next week. Please expect a delay in responses and an update following his return.

Thanks,

Chris

RE: AM62A7-Q1: AM62A74 with 16-bit LPDDR4

Christopher Roberts — Wed, 24 Jun 2026 18:28:54 GMT

Hello Nikunj,

The assigned expert is currently out of office, returning next week. Please expect a delay in responses and an update following his return.

Thanks,

Chris

AM62A7-Q1: AM62A74 with 16-bit LPDDR4

Nikunj Zadeshwariya — Wed, 24 Jun 2026 11:21:23 GMT

Part Number: AM62A7-Q1

Hi,

I am planning to interface 16-bit LPDDR4 with AM62A74. Refering to:www.ti.com/.../sprad66b.pdf , I understand that is possible with 16-bit single rank LPDDR4

1) Please confirm whether the understanding and approach is correct or not.

2) Suggest compatible 16-bit LPDDR4 devices.

3) Expliit design guidelines to be taken care for the same.

Thanks,

Nikunj

RE: AM6422: AM6422 PCIe root complex (TI PCI Bridge dev B010) does not enumerate reliabily; nor does its child device, even when it does.

John Hentges — Wed, 24 Jun 2026 18:23:38 GMT

We've discovered this missing from the .dts file:

&main_pmx0 {
    pcie0_perst_pins_default: pcie0-perst-default-pins {
        pinctrl-single,pins = <
            AM64X_IOPAD(0x0090, PIN_OUTPUT, 7) /* (P17) GPMC0_BE0n_CLE.GPIO0_35 */
        >;
    };

Adding that enables control of GPIO 35, where our PERST# is connected.
With a unit booted into the "RC present, FPGA missing" failure state, pulsing that low and issuing a PCI bus rescan does not recover the FPGA in lspci. Manually causing LTSSM remains stuck in "Training" state=1, as before.

AM6422: AM6422 PCIe root complex (TI PCI Bridge dev B010) does not enumerate reliabily; nor does its child device, even when it does.

John Hentges — Tue, 23 Jun 2026 19:00:37 GMT

Part Number: AM6422

We've implemented a custom DAQ device via a PCI Express FPGA hanging off the AM64x PCI Express Root Complex (00:00.0 PCI bridge: Texas Instruments Device b010, in lspci).

This worked flawlessly with SDK 8 (arago.2023-10), on dozens of units shipped, but has caused recurring, intermittent, problems in SDK 9 (arago.2025-01)

Roughly 10% of boots from the eMMC will fail to detect the TI PCI Bridge / RC. No recovery techniques have succeeded other than simple reset.

Of the 90% of boots where the RC does appear, our FPGA does not, also about 10% of the time.

With a unit in this state (RC but no FPGA) I was able to determine the LINKSTATUS was "1" (in training phase) rather than "3" (ready). Using devmem2 to cause a do-over showed the state=1 for almost 2 seconds, then state=0 ("no receiver").

A simple reset recovers, again, about 81% of the time. A Linux "reboot" command never recovers from this state.

Note the FPGA is a Cyclone IV GX, and it and its PCIe interface are identical to what we use in scores of PCBA models in tens of thousands of shipped products, successfully (all non-Sitara designs that interface to x86/x64 desktop/SFF PCs or SBCs via PCIe, M.2, and/or mPCIe slots, et al).

AM4376: AM4376 Documentation on how to add secure keys

Bailey Looper — Wed, 24 Jun 2026 18:02:13 GMT

Part Number: AM4376

My customer is investigating CRA for their current products. They are using variants of the AM4376. The part numbers they have used for this are below:

AM4376BZDNA100

AM4376BZDNA80

They have used the AM62A on newer projects and are familiar with the key writer method: https://dev.ti.com/tirex/explore/node?node=A__AagJ-8QGXM582KzTgxFZbA__AM62-ACADEMY__uiYMDcq__LATEST

They're understanding from their investigation is they will need to transition to a version of AM4376 with security keys. They will need to rework board and figure out how to add the security keys (they hope that we can copy AM62A method linked above.

My questions are:

The AM437x device datasheet says security keys are only available on AM437xHS devices, what are the OPNs that are considered "AM437xHS devices" for the AM4376 variant? My customer said they are interested in AM4376BZDNA100S but I could not find this OPN on ti.com and it is not clear from the DS.
Is there information on the Keywriter for AM4376 HS device that you can share with me to share with my customer? Similar to what is linked above for AM62x in the AM62x academy (https://dev.ti.com/tirex/explore/node?node=A__AagJ-8QGXM582KzTgxFZbA__AM62-ACADEMY__uiYMDcq__LATEST). I could not find anything in the SDK release notes for AM4376 (https://software-dl.ti.com/processor-sdk-linux/esd/AM437X/11_02_05_02/exports/docs/devices/AM437X/linux/index.html) and I couldn't find anything in the AM62Ax release notes either (https://software-dl.ti.com/processor-sdk-linux/esd/AM62AX/11_01_07_05/exports/docs/devices/AM62AX/index.html)
Is the Keywriter process for AM4376 HS and AM62Ax devices at all? Will they be able to copy what they did for AM62A? If they are different, can you help me understand how different?

Thank you.

RE: AM4376: AM4376 Documentation on how to add secure keys

Bailey Looper — Wed, 24 Jun 2026 18:21:47 GMT

For question 3 I meant to ask if the keywriter process for AM4376 and AM62Ax was similar at all.

TDA4VH-Q1: LPDDR4 devices in EVK - Change to Single memory from four

Johnson John — Fri, 12 Jun 2026 13:27:24 GMT

Part Number: TDA4VH-Q1

Hi TI Expert Team,

We have the TDA4VH EVM module (J784S4XG01EVM) for our evaluation and would like to test our software application with a reduced LPDDR memory configuration (8GB).

As per the current EVM setup, there are 4 × LPDDR4 devices (32 GB total) on the board.

Could you please suggest how to disable three LPDDR4 devices on the board, either through hardware or software configuration?

Your support is greatly appreciated.

Regards,
Johnson John

RE: TDA4VH-Q1: LPDDR4 devices in EVK - Change to Single memory from four

Suman Anna — Wed, 24 Jun 2026 17:20:32 GMT

Hi Jenius,

[quote userid="683820" url="~/support/processors-group/processors/f/processors-forum/1654992/tda4vh-q1-lpddr4-devices-in-evk---change-to-single-memory-from-four/6393714"]Now if I try to add the vision apps dtbo, Kernel panic was showing.[/quote]

Yes, this is expected. You cannot use the default Vision Apps dtbo file, as it is using memory beyond the 8 GB (0xA_0000_0000) memory addresses. You would need to adjust the memory map and re-build all the Vision Apps firmwares that are using a suitable memory map.

[quote userid="683820" url="~/support/processors-group/processors/f/processors-forum/1654992/tda4vh-q1-lpddr4-devices-in-evk---change-to-single-memory-from-four/6393714"]Please help us to map the memory for R5F and C7X cores.[/quote]

I consider this ticket resolved w.r.t required changes on the Linux U-Boot and Kernel. I am not sure what your overall usecase is or the motivation to use the TDA4VH (J784S4) but only 1 DDR Controller, rather than using a smaller TDA4 device (like TDA4VL/J721S2, or TDA4VPE/J742S2 or even TDA4VM/J721E).

In anycase, please open a new thread using "Ask a related question" regarding the RTOS related changes.

Please do use the following references:

1. 9.9. Understanding and updating SDK memory map for J784S4

2. [FAQ] TDA4VM: TDA4VM/TDA4VL/TDA4AL/TDA4VH/DRA821: Custom DDR Memory Mapping for Vision Applications on Jacinto SoCs

The first link is an SDK documentation that provides details on customizing the memory-maps, and the second one is a reference that uses an even smaller 2 GB DDR Configuration.

regards

Suman

RE: AM625: Git is down - cannot build/update etc

Vinuchandran A V — Wed, 24 Jun 2026 17:10:30 GMT

Hi Jason,

It seems that the issues are not completely resolved yet.

IT is working on it.

Regards,
Vinu

AM625: Git is down - cannot build/update etc

Jason Gauthier — Mon, 22 Jun 2026 13:09:01 GMT

Part Number: AM625

Maybe by the time this is posted and reviewed the issue will be corrected.
But as of right now, on 06/22/2026, at 9:05AM EST, https://git.ti.com is innaccessible. It has been inaccessible for the last hour (estimated)

I cannot update firmware, u-boot, or build my yocto images currently.

fatal: unable to access 'https://git.ti.com/git/ti-u-boot/ti-u-boot.git/': Recv failure: Connection reset by peer

AM3352: ti-sysc: Failed to create device link 0x180 with supplier for timer1 and timer2

Lucas Martins Alves — Fri, 19 Jun 2026 20:08:49 GMT

Part Number: AM3352

Hello,

I am working with an AM3352-based platform and have observed the following messages during Linux boot:

ti-sysc 44e31000.target-module: Failed to create device link 0x180 with supplier ocp for /ocp/interconnect@44c00000/segment@200000/target-module@31000/timer@0
ti-sysc 48040000.target-module: Failed to create device link 0x180 with supplier ocp for /ocp/interconnect@48000000/segment@0/target-module@40000/timer@0

From my current understanding, these messages seem to be related to the TI SYSC interconnect driver attempting to create device links for timer modules. I suspect this may be associated with flag 0x180 (DL_FLAG_SYNC_STATE_ONLY) and possibly because the timer device has already been probed.

I also noticed that the same message appears in Texas Instruments' own CI test logs for AM335x platforms. For example:

https://software-dl.ti.com/cicd-report/linux/index.html?section=test_log&platform=am335x&snapshot=cicd.master.202605061800&board=am335x-evm&variant=Linux&test=LCPD-T826&log=dut1_1_log.txt

This suggests that the issue might be known and possibly benign, but I would appreciate clarification.

My questions are:

- Does this issue have any functional impact?
The system appears to operate normally, but I would like to know whether this may affect power management, clock handling, or runtime PM behavior.

- Is there a recommended way to fix or avoid this message?
For example:
- Device Tree adjustments
- Kernel configuration changes
- Known upstream patches

- If this message is harmless, what would be the recommended way to suppress or reduce it in the boot logs?

Any insights or recommendations would be greatly appreciated.

Thank you!

RE: AM3352: ti-sysc: Failed to create device link 0x180 with supplier for timer1 and timer2

Wagner Popov dos Santos — Wed, 24 Jun 2026 16:58:17 GMT

Hi Bin,

I found the root cause and a working fix. Timer1 and Timer2 are initialized before the OCP interconnect. Later, when OCP is probed and tries to create device links to these timers, the kernel reports the device-link creation errors.

The fix is to add the post-init-providers property to Timer1 and Timer2, so dependency resolution reflects that OCP is available after the timer initialization stage. This prevents the invalid link-creation attempt and removes the related boot log errors.

The patch for the am33xx:

From d16536280ef80bef39cdb4c111ef66407b8bbd24 Mon Sep 17 00:00:00 2001
From: Wagner Popov dos Santos <wagner.popov@autotrac.com.br>
Date: Wed, 24 Jun 2026 13:28:02 -0300
Subject: [PATCH] ARM: dts: am33xx: avoid invalid OCP device-link for timers

This patch fixes boot-time fw_devlink errors on AM335x/UCC3 caused
by invalid device-link creation attempts involving timer1/timer2
and supplier ocp.

Observed kernel log messages:

  ti-sysc 44e31000.target-module: Failed to create device link 0x180
  with supplier ocp for
  /ocp/interconnect@44c00000/segment@200000/target-module@31000/timer@0

  ti-sysc 48040000.target-module: Failed to create device link 0x180
  with supplier ocp for
  /ocp/interconnect@48000000/segment@0/target-module@40000/timer@0

The change updates dependency handling for timer1 and timer2 so the
kernel no longer attempts this invalid link-creation path during
initialization.

Impact:

- Removes the two ti-sysc/fw_devlink error messages at boot
- Preserves current timer and clock assignment behavior
- No functional regression observed in boot and timer operation tests

Signed-off-by: Wagner Popov dos Santos <wagner.popov@autotrac.com.br>
---
 arch/arm/boot/dts/ti/omap/am33xx.dtsi | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm/boot/dts/ti/omap/am33xx.dtsi b/arch/arm/boot/dts/ti/omap/am33xx.dtsi
index ca3e7f5d7d0d..760598d5ae1c 100644
--- a/arch/arm/boot/dts/ti/omap/am33xx.dtsi
+++ b/arch/arm/boot/dts/ti/omap/am33xx.dtsi
@@ -708,6 +708,7 @@ &timer1_target {
 	timer@0 {
 		assigned-clocks = <&timer1_fck>;
 		assigned-clock-parents = <&sys_clkin_ck>;
+		post-init-providers = <&ocp>;
 	};
 };
 
@@ -721,5 +722,6 @@ &timer2_target {
 	timer@0 {
 		assigned-clocks = <&timer2_fck>;
 		assigned-clock-parents = <&sys_clkin_ck>;
+		post-init-providers = <&ocp>;
 	};
 };
-- 
2.43.0

AM62L: AM62L SDIO_LDO capacitor

DAVID NEPERUD — Wed, 24 Jun 2026 16:54:32 GMT

Part Number: AM62L

The datasheet says for the SDIO LDO pin

This pin must always be connected via a 6.3V or greater, 3.3 uF ± 20% capacitor to VSS when the SDIO_LDO is being used to source VDDSHV3. The capacitor selected must provide a capacitance within the defined range after it has been derated for DC-bias, operating temperature, and aging effects. Otherwise, this pin may be connected directly to VSS when the VDDA_3P3_SDIO pin is also connected directly to VSS.

What is the "defined range" for the capacitance after it has been derated?

3.3uF is a difficult value to find, especially in a 0402 size part which is required in my design for fit. Can a 4.7uF value 0402 capacitor be used instead?

TDA4VH-Q1: J784S4 and AM69A Processor SDK compatibility

Christophe Van Delsen — Thu, 18 Jun 2026 09:26:33 GMT

Part Number: TDA4VH-Q1

Hello TI Experts,

I have both the J784S4XEVM and SK-AM69A boards on which I want to evaluate SW performance. Can both platforms be supported with a single Processor SDK Linux installation? I lack the disk space to support full Yocto builds on both SDKs individually, and I was wondering whether a single installation can handle both boards. The SDK documentation seems to hint at that by setting the MACHINE variable, e.g.,

MACHINE=<machine> bitbake <target>

Then again, the J784S4 SDK has 11.02.00.04 as latest release, while the AM69A SDK only goes up to 11.00.00.08. So, before I would start the exercise with a single SDK installation, I would like confirmation whether or not a single installation is sufficient. And if so, which SDK version would be most suitable for that?

Kind regards,

Christophe

RE: TDA4VH-Q1: J784S4 and AM69A Processor SDK compatibility

Suman Anna — Wed, 24 Jun 2026 16:47:50 GMT

Hi Christophe,

[quote userid="698598" url="~/support/processors-group/processors/f/processors-forum/1656575/tda4vh-q1-j784s4-and-am69a-processor-sdk-compatibility/6393779"]Thank you for the heads-up. Very useful to know about the updated support model.[/quote]

Sure. The Linux SDKs are built using public git trees, so you could try building on your own, but TI does not perform any validation with the latest code baseline on the AM68A/AM69A SK boards.

regards

Suman

AM62P: Design File Review

Brian Wang — Fri, 05 Jun 2026 12:20:59 GMT

Part Number: AM62P

As discussed with Sreenivasa, I am creating an E2E thread for tracking and direct queries or clarifications from the schematic review. Any important observations can be shared directly over private chat or email.