Using the debugger to extract the UUID from JTAG (IMX8DX)

[krassimirestoya]

Hi,

We need to get a locked device to PFR (Partial Field Return) state. One of the steps is:

1. Extract the IMX8 UUID

1. Use the debugger to extract the UUID from JTAG.

I searched the Web and the NXP community, but was unable to find a clear answer:

1. To which core we need to connect? If SCU, can NXP help with lauterbach script?

2. Which address to read from memory? The information is confusing, shadow offset 0x410? In the same time I find this:

krassimirestoya_0-1787634654087.png

So what in the end to read? is the base address 0x30350000?

[yipingwang]

For i.MX8 / i.MX8X SCU-based devices, connect the debugger to the SCU core , not an A-core, for this UUID/PFR workflow. The Lauterbach material in the NXP knowledge base shows Trace32 attaching to IMX8QXP-SCU for SCFW/JTAG work, and the SCFW monitor/API path is the documented way to obtain the device unique ID.

The address confusion comes from mixing i.MX8M-style OCOTP mapping with SCU-based i.MX8 / i.MX8X fuse naming :

• Do not use 0x30350000 for i.MX8QM/QXP/8X SCU-based parts. That 0x3035_0000 OCOTP base is documented for i.MX8M-family devices; the i.MX8QM documentation instead shows the OCOTP base address as 0h .
• The 0x410 value is not the byte address to read . In the i.MX8 documentation it appears as the fuse address / fuse word index range for SJC_CHALL[63:0] / UNIQUE_ID[63:0] .
• In the OCOTP register map, HW_OCOTP_FUSE410 is at offset 0x21A0 , and HW_OCOTP_FUSE420 is at offset 0x2240 .
• The fuse map also describes the unique ID as shadowed at 0x0900–0x0910 , fuse row index 16–17 , and explicitly says sc_misc_unique_id() can return the device unique ID.

So the answer is:

• Preferred / documented method: use SCFW:

• SCFW API: sc_misc_unique_id(ipc, &ID_L, &ID_H) returns the 64-bit ID as low and high 32-bit words.

• SCFW monitor, if available: info or seco info displays SoC/SECO information including unique ID / lifecycle-related data.

• If doing raw JTAG memory/register access on SCU-based i.MX8/QXP/QM:

• attach Trace32 to the SCU target ;

• do not read 0x30350000 + 0x410 ;

• treat 0x410 / 0x420 as fuse word identifiers, whose OCOTP register-map offsets are 0x21A0 and 0x2240 respectively.

• If the device is actually i.MX8M / i.MX8MM / i.MX8MP , then 0x30350000 is the OCOTP base used by that family, and the Linux device tree exposes OCOTP at 30350000 with unique-ID-related nvmem cells. That is a different access model from SCU-based i.MX8QM/QXP.

For a Lauterbach script: the public material confirms the Trace32 target selection path — attach to IMX8QXP-SCU — but I did not retrieve a complete NXP-published PFR UUID extraction script. The script should read via the SCU/SCFW path above, or directly read the OCOTP fuse register offsets only if the SCU-side address map and access permissions are confirmed for the exact SoC/revision.

Fi.MX8QM/QXP/8X, connect to the SCU; 0x30350000 is the wrong base for this flow, and 0x410 is a fuse index, not the memory address to read.

[krassimirestoya]

So on IMX8DX I should read from 0x000021A0 address?
Can you give me the Trace32 script to connect to SCU core?

[yipingwang]

Yes — 0x000021A0 falls inside the SCU ROM window, because the i.MX 8X reference manual maps 0x0000_0000–0x000F_FFFF to ROM – SCU . To read it as the SCU sees it, connect through the SCU M0+ debug/memory access port; the DAP port map lists Port 3 as “Debug/ Memory access to SCU M0+.”

NXP docs reference Lauterbach’s coresight-scu.cmm for SCFW/SCU attach, but the retrieved NXP material does not include the actual script body. A minimal TRACE32 attach script would look like this:

; attach_scu_imx8dx.cmm

; Minimal SCU M0+ attach for i.MX8DX / i.MX8X-class device

RESet

SYStem.CPU CortexM0+

SYStem.JtagClock 10MHz

; Select the CoreSight AP used for SCU M0+ debug/memory access.

; i.MX8X DAP Port Map: Port 3 = SCU M0+ debug / memory access.

SYStem.CONFIG DAPACCESSPORT 3

; Attach without resetting the target

SYStem.Mode Attach

; Stop SCU core if required

Break

; Read the SCU ROM address

Data.List 0x000021A0

Data.Long 0x000021A0

If your TRACE32 build does not accept SYStem.CONFIG DAPACCESSPORT 3 , use Lauterbach’s packaged i.MX8 script name directly if available:

DO ~~/demo/arm/hardware/imx8/coresight-scu.cmm

Data.List 0x000021A0

Data.Long 0x000021A0

If the goal is to inspect SCFW RAM rather than Boot ROM, use the SCU TCM regions instead: TCML is 0x1FFE0000–0x1FFFFFFF , and TCMU is 0x20000000–0x2001FFFF .

Takeaway: read 0x000021A0 only when you intend to access SCU ROM; connect TRACE32 to the SCU M0+ through DAP Port 3, then read that address from the SCU view.

[krassimirestoya]

Let's verify the procedure.

I attached to the SCU core and found at address 0x000021A0

krassimirestoya_0-1787739370611.png

Then, at address 0x00002240 I see:

krassimirestoya_1-1787739425460.png

Is the UID equal to 0xF4400010FA82F007 ?

[yipingwang]

What SCFW version are you using? If you have the SCFW console, the easy way is to send command "seco info" or "info" to get UID values.

After attaching SCU core, please try the attached script, the WORD3 and WORD4 should be the chip UID.