From the J722S EVM to a Production AM67A Board: What Actually Changes

A system running on an AM67A development board is not a product you can manufacture. The gap is not only drawing a board, either: some decisions lock in a way that cannot be undone, and several of them are made before the board is drawn — when the order code is chosen.

One thing needs saying up front: it is not true that TI publishes no hardware design collateral for this part. It publishes more than thirty documents. The problem is not absence — it is that they are spread across three different part names, and nowhere is it written down which decision locks in which document. This page works out that order. Every value below comes from the AM67x datasheet SPRSPA3B (March 2024, revised June 2026), cited by section. Spikedge has not built a production board with this part; there is no field data, yield figure or measurement on this page.

The ledger of irreversible decisions

Not every decision on the road to production is equal. Some are undone with a software update, some with a board revision, and some not at all. In order:

There is only one way to read this table: the further down you go the more expensive reversal becomes, and the hardest row is not at the bottom — it is the eFuse row.

eFuse: the datasheet's bluntest paragraph

Under §6.8.4, "Impact to Your Hardware Warranty", the datasheet says something with a clarity technical documents rarely reach. In substance:

• You accept that eFusing the device with security keys permanently alters it.
• The eFuse can fail — through an incorrect or aborted programming sequence, or because you omitted a step.
• If the error-correction check fails for the production keys, or the image is not signed (and optionally encrypted) with the current active production keys, the device fails to secure boot.
• These situations render the device inoperable, and TI is unable to confirm whether the part conformed to its specifications before the attempted eFuse.
• Consequently, TI has no liability, warranty or otherwise, for devices that customers have incorrectly eFused.

The hardware requirements attached to it sit in the same section:

• eFuse programming is done by applying voltage to the VPP pin: 1.71 – 1.89 V (1.8 V nominal), up to 400 mA, with a power-up slew rate no greater than 6 × 10⁴ V/s.
• Junction temperature during programming must be within 0 – 85 °C — a far narrower window than the part's general operating range.
• VPP must be disabled whenever you are not programming. In normal operation it is left unconnected (NC) without programming hardware support, or held at 0 V with it.
• VPP must be ramped up after the proper device power-up sequence.
• The OTP write software is not in any repository; the datasheet says to contact your local TI representative for the package.

Four consequences land directly on the board design: a switchable, measurable 1.8 V supply for VPP; a test station that holds the part below 85 °C during programming; a power architecture that will not let the sequence abort halfway; and a written procedure for a production-line step that runs exactly once. None of these exist on a development board.

Device type: what the part arrives as, and what it becomes

The datasheet does not describe this transition — the strings HS-FS, HS-SE and keywriter appear nowhere in the full text of SPRSPA3B. The flow lives in separate TI documents:

• HS-FS (High Security – Field Securable): the customer key area is blank. This is the state the part arrives in.
• HS-SE (High Security – Security Enforced): the state after the customer has programmed their own roots. TI describes this as a production device.
• The transition is made with the OTP Keywriter: the customer root key set — and optionally a backup set — is programmed onto the target device.
• In TI's own words: "The process is irreversible once the eFuse is programmed by customer keys."

Three warnings:

1. The document describing this flow is not AM67A-specific. SPRAD04 is dated January 2022 and written around the J721E/TDA4VM generation; the strings J722S, AM67, TDA4VEN and TDA4AEN never appear in it. For this part the current authorities are the TRM (SPRUJB3D) and the TISCI Key Writer documentation; SPRAD04 gives you the shape of the flow, not the device detail.

2. The key format differs on this part. The Key Writer documentation states that EC keys for SMPK and BMPK are supported on am62x, am62ax, am62px, am64x and am275. J722S/AM67A is not on that list — so here the key set is RSA-4096. Build your key infrastructure, HSM and signing flow around that. It is not a detail you change later.

3. The return process is not a way back. TI's HS Device Customer Return Process note (SPRADG2) describes unlocking the JTAG debug port on a returned device through a UID-bound signed certificate. The eFused customer keys stay burned. It is a debug path, not a way to undo key programming.

What the order code commits you to

Table 9-1 decodes every field of the part number. The field order is: a + base part number + r (revision) + Z (speed grade) + f (features) + Y (security) + t (temperature) + package + R.

Now apply that to the four part numbers in the Package Option Addendum of SPRSPA3B (dated 15 August 2025) — each is listed with a .B row as well, eight rows in total:

AM67A94AKGHIAMWR · AM67A74AKGHIAMWR · AM6754AKGHIAMWR · AM6734AKGHIAMWR

Decoded field by field, all four say the same thing: A (SR 1.0) · K (speed grade K) · G (base features) · H (security field, the first value of the H–R range) · I (temperature) · AMW package · R tape-and-reel.

Three practical consequences follow:

1. Speed grade J is not on the list. All four catalogue parts are grade K. Per the speed grades table, J's nominal core voltage is 0.75 V and K's is 0.85 V; LPDDR4 rate is 3200–3733 for J and 3466–4000 MT/s for K. So your power design has to be built around a 0.85 V core rail, not 0.75 V. (The addendum is dated August 2025 and the datasheet body June 2026; if grade J parts are added later this changes — confirm with TI before ordering.)

2. The security field is not blank. In all four, Y is H, not G. Table 9-1 defines the H–R range as "secure with production key". Footnote 2 of Table 4-1 ties the availability of device security features — including secure boot and customer programmable keys — directly to this Y identifier. Plan your secure-boot architecture accordingly; for the key programming flow itself, see TI's Jacinto7 HS Device Development note (SPRAD04) and the TISCI Key Writer documentation.

3. There is a three-way temperature contradiction inside the document. Table 9-1 defines t = I as –40 °C to 105 °C, and in parentheses sends the reader to "Recommended Operation Conditions". But in Rev B, that table in §6.4 contains exactly one TJ row: test condition "125°C Industrial and Automotive", MIN –40, MAX 125 °C. There is no 105 °C row in it. The Package Option Addendum, for the same part numbers, prints –40 to 125 in the "Op temp (°C)" column.

So the I field in the order code cross-references a table that no longer contains the range it names. 105 °C has not vanished from the datasheet entirely — it keeps its own row in the POH table in §6.3. For contrast: the AM62Ax datasheet names both grades explicitly, in both its POH table and its operating conditions, as EXTENDED (–40 to 105 °C) and AUTOMOTIVE (–40 to 125 °C). The AM67x datasheet does not.

This page does not resolve it: ask TI before you base a thermal budget on either. Choosing the wrong one feeds straight into the POH table below, and from there into product lifetime.

Power-On Hours: the one table that binds product lifetime

Section 6.3 is among the most binding tables in the document for a series product, and among the least often opened:

The footnotes matter more than the table:

• One of the two profiles is chosen and applied through the lifetime of the application. Mixing them to extend temperature or POH may result in increased reliability failure risk, and TI does not recommend it.
• The 125 °C profile is not merely "20,000 hours" — it is defined with a specific temperature distribution: 5% at −40 °C, 65% at 70 °C, 20% at 110 °C, 10% at 125 °C. If your thermal design does not hold that distribution, the 20,000-hour figure is not yours to use.
• POH is a function of voltage, temperature and time; higher voltages and temperatures reduce it.

100,000 hours is about 11.4 years of continuous operation; 20,000 hours is about 2.3 years. The difference between those two is a product decision, not a thermal-design detail. Combined with the temperature contradiction above: if you do not know which POH row you are in, you do not know your product's service life.

Thermal: which number you are allowed to use, and when

Section 6.9.1 gives these values for the AMW package:

The footnote is what counts: these values are based on a JEDEC-defined 2S2P system (except RΘJC, which is based on a 1S0P system) and will change based on environment and application. The datasheet then says what to do about it: "It is recommended to perform thermal simulations at the system level with the worst case device power consumption."

So RΘJA = 12.6 °C/W is not your board's number — it is the JEDEC test board's number. If your board is not a four-layer reference stack-up, if your copper area differs, if neighbouring components are adding heat, that figure is not real for you. The production decision comes from your own simulation, and for the "worst case power consumption" that simulation needs as input, §6.6 points you at the Power Estimation Tool (SPRUJD0).

Power: not a sequence, but the gap between rails

On a development board power is already solved; on a production board you solve it. Here the datasheet keeps its hardest rules in the footnotes.

Shared-source requirement. Footnote 2 of §6.4 requires these rails to be sourced from the same power source: VDD_CORE, VDDA_CORE_CSI_DSI, VDDA_CORE_CSI_DSI_CLK, VDDA_CORE_USB0, VDDA_CORE_USB1 and VDDA_DDR_PLL0. It further advises that care be taken to hold the VDD_CORE-to-VDDA_CORE_USB differential within ±1%.

The rule is not an ordering list — it is a differential limit. The footnotes to Table 6-6 in §6.11.2.2.1 state the condition as an instantaneous voltage difference rather than a sequence:

• VDDR_CORE must never exceed VDD_CORE + 0.18 V during power-up or power-down (note 12).
• When VDD_CANUART is connected to an always-on source, VDD_CORE must never exceed VDD_CANUART + 0.18 V — which requires VDD_CANUART to ramp up before and down after VDD_CORE (note 9).

The distinction matters in practice: you cannot verify this by checking the power-up order alone. Even with the order correct, the difference between two rails can momentarily exceed 0.18 V during the ramps. Verification means measuring the differential across the ramp.

Ramp slew rate. To protect internal ESD structures, the datasheet recommends keeping supply ramp slew below 18 mV/µs — which for a 1.8 V supply means a ramp longer than 100 µs.

And the power number is not in the datasheet. Section 6.6 gives no power consumption values at all; it delegates the subject entirely to the Power Estimation Tool (SPRUJD0, July 2024). That tool also outputs a table of PDN currents at TJ = 125 °C or 105 °C. The input to your thermal simulation comes from there — it cannot be read out of the datasheet.

Layout: the two places TI actually imposes a rule

Most of the datasheet informs. Two sections impose.

LPDDR4

The closing line of §8.2.1 is not open to negotiation: "TI only supports board designs using LPDDR4 memories that follow the guidelines in this document." The document is Jacinto 7 LPDDR4 Board Design and Layout Guidelines (SPRACN9 Rev. F). The layout and routing rules live there; they are too specific to paraphrase and must be read from the guide itself.

A second warning attaches to it, in footnote 2 of the speed grades table: maximum DDR frequency is limited both by the memory type (vendor) used and by the PCB implementation. The datasheet also recommends that software use the minimum LPDDR4 transfer rate that satisfies the system's performance requirement — in production, that is margin on both power and signal integrity.

OSPI / QSPI / SPI

Here (§8.2.2.1) the numeric rules are inside the datasheet itself:

• The OSPI[x]_CLK output pin must be connected to the CLK input pin of the attached device.
• Propagation delay from OSPI[x]_CLK to the attached device's CLK pin must be ≤ 450 ps (roughly 7 cm as stripline, 8 cm as microstrip).
• Each OSPI[x]_D[y] and OSPI[x]_CSn[z] delay must be matched to the clock delay within ±60 ps.
• 50 Ω PCB routing with series terminations is recommended.

On a production board that boots from OSPI these four lines are the design's acceptance criteria. For field behaviour, also read the OSPI Tuning Procedure (SPRACT2).

Pin muxing: a feature list is not a schematic

The note directly under Table 4-1 warns of the most expensive surprise waiting for teams starting board design: availability of the features in that table is a function of shared IO pins. Signals associated with many of the features are multiplexed onto a limited number of pins. The datasheet says to use SysConfig to assign signal functions to pins, and adds that this is how you understand the limitations that multiplexing imposes.

In practice: a design that reads four CSI-2 inputs, PCIe, USB 3.0, three CAN-FD and nine UARTs off the feature list and puts them all on the schematic may find, on opening SysConfig, that some of them cannot be brought out at the same time. That check happens before the schematic is drawn, not after.

What changes on the software side

When the hardware changes the software changes with it, and three items here separate a production board from a development board:

1. Is the feature actually supported? The datasheet does not answer this itself; the note under Table 4-1 directs the reader to the Software Build Sheet — separately for PROCESSOR-SDK-AM67 and PROCESSOR-SDK-AM67A. That document sits in the downloads tab of the SDK page. It is the first step in validating an architecture plan: a feature present in silicon may have no driver in the SDK.

2. The device tree does not carry your board's name. In mainline Linux every SoC-level file is named k3-j722s*; the ones named am67a are board-level. The .dts you write for your production board describes your layout, not the EVM's, and sits on top of k3-j722s-main.dtsi.

3. Which page did your SDK come from? The AM67A-branded and J722S-branded SDK pages do not move at the same pace, and the R5F and C7x side exists only on the J722S page. That split is covered in full in the AM67A / J722S documentation map, and how TIDL artifacts bind to the SDK version in TIDL model deployment.

Read these before starting board design

The "family-wide" note on the last three matters: those documents are written for the Jacinto7 family, not specifically for the AM67A. Do not assume every step in them applies verbatim to this part; cross-check against the datasheet and TRM.

And the errata carries a trap of its own: the errata is April 2025, the datasheet June 2026. The errata is older than the document it qualifies. Before starting board design, confirm the current revision of both directly with TI.

What this page cannot tell you

The following need hardware and field experience. Because Spikedge has not built a production board with this part, no estimate is offered here:

• The real RΘJA of a specific layout, and which TJ is reached at which wattage.
• How the power profile changes with four CSI-2 cameras at full load, and what that does to power sequencing.
• How long the eFuse programming step takes on a production line, and at what failure rate.
• How far the LPDDR4 rate can practically be pushed on a given board.

When these are measured, the results will be published with their conditions under technical proofs.

Related Spikedge pages

• AM67A vs AM62A processor selection — the decision before the order code
• TI AM67A SoC architecture — blocks and variant differences
• AM67A / J722S documentation map — which document holds what
• AM67A TIDL model deployment — getting the model into the BSP
• T3 Gemstone O1 technical analysis — one AM67A board, read from its schematic