I2S2 master clocks are generated internally but never reach the 40-pin header: Jetson Pack 7 / L4T R39.2

Robotics & Edge Computing Jetson Systems Jetson Orin Nano
, ,
1

With I2S2 as clock master and a stream running, there is no BCLK (pin 12), FS (pin 35),

DOUT (pin 40) or MCLK (pin 7) on the 40-pin header — yet every register, the clock and the pinmux read correct. The same pads drive a clean 3.3 V in GPIO mode.

How to reproduce: raw ALSA, no custom code. (The stock DT leaves the I2S2 DAP with no codec, so we bound a dummy spdif-dit codec to it to complete the audio-graph DAI link.)

# Terminal 1 — route + master/frame mode, then start the stream and LEAVE IT RUNNING:

amixer -c APE cset name='I2S2 Mux' 'ADMAIF1'

amixer -c APE cset name='I2S2 codec master mode' 'cbs-cfs'

amixer -c APE cset name='I2S2 codec frame mode'  'i2s'

speaker-test -D hw:1,0 -c 2 -r 48000 -F S32_LE -t sine

Verified correct in a second terminal, while Terminal 1 keeps streaming

cat /sys/kernel/debug/regmap/2901100.i2s/registers (key offsets):

# cat /sys/kernel/debug/regmap/2901100.i2s/registers (key offsets):

00: 00000001    # RX_ENABLE  = 1       playback path enabled

0c: 00000001    # RX_STATUS  = 1       active

40: 00000000    # TX_ENABLE  = 0       capture off (correct)

80: 00000001    # I2S_ENABLE = 1

88: 00000001    # I2S_CG     = 1       clock gate open

a0: 00000407    # I2S_CTRL   = 0x407   MASTER_EN=1 (master) + 32-bit

a4: 0000001f    # I2S_TIMING = 0x1f    32-bit slot width — non-zero, programmed

# grep i2s2 /sys/kernel/debug/clk/clk_summary` (clock · enable_cnt · prepare_cnt · protect · rate):

i2s2   1   1   0   3071997   ...   Y   i2s@2901100      # enabled, prepared, ~3.072 MHz

# /sys/kernel/debug/pinctrl/2430000.pinmux/pinconf-groups` — the three I2S2 output pads:

141 (soc_gpio41_ph7):  tristate=0  enable-input=0     # BCLK

142 (soc_gpio42_pi0):  tristate=0  enable-input=0     # DOUT

144 (soc_gpio44_pi2):  tristate=0  enable-input=0     # FS

NOTE: driving each pad as a GPIO puts 3.3 V on the header pin (scope-confirmed → pad/trace

good). In i2s2 mode, a wiring-validated scope reads 0V.

These are my questions:
The carrier spec (SP-11324-001 v1.3, Table 3-3, Note 3) says these audio pins go through TI TXB0108 level translators. Is the 40-pin header expected to carry a 3.072 MHz I2S master bit clock (and even the 48 kHz FS) out through the TXB0108 at all, or is that a known limitation of this dev kit? Since the TXB0108 is auto-direction there is no DIR/OE GPIO to set — correct?

And is there a SoC-side (1.8 V) test point before the translator we can probe to confirm the DAP output is actually driving?

I’ve attached the Device Tree Source (`.dts`, human-readable) overlays used during my tests:

  • jetson-io-hdr40-user-custom.dts (the 40-pin header pinmux)
  • tegra234-i2s2-dummy-codec.dts (the dummy-codec overlay that completes the I2S2 DAI link).

Thank you and Best Regards,
Gilberto

dts.zip (2.5 KB)

3

— 🤖 This is an automated AI response. I’m here to help, but please verify important details! —

To address the issue of Jetson Orin Nano I2S2 master clocks not reaching the 40-pin header, we need to consider the configuration and setup of the I2S2 interface. The provided context indicates that the I2S2 DAP is configured as a master, with the clock and frame mode set appropriately, and a dummy codec is bound to it to complete the audio-graph DAI link.

Given the information and the steps you’ve taken to reproduce the issue, including verifying the correctness of the register settings and the clock enablement, it seems there might be a misunderstanding or an oversight in the configuration or an issue with the hardware setup.

  1. Clock and Pinmux Configuration: Ensure that the clock configuration for I2S2 is correctly set and that the pinmux settings for the 40-pin header are properly configured for I2S2 output. The context you provided shows that the registers are set to enable I2S2 as a master and that the pinmux settings seem correct for GPIO mode but not for I2S2 mode.

  2. Direction-Controlled Level Translator: The question about a direction-controlled level translator is crucial. Typically, for signals to be driven out of the Jetson module and onto the 40-pin header, especially for audio interfaces like I2S, the signals need to be properly buffered or level-shifted to ensure compatibility with the external circuitry. If such a translator exists and its direction is controlled by a GPIO, you would need to ensure that this GPIO is properly set to enable output.

  3. Erratum or Extra Pad Enable: Sometimes, specific errata or additional configuration steps are required for certain features to work correctly, especially on complex SoCs like those found in the Jetson series. Check the official NVIDIA documentation and any errata notices for the Jetson Orin Nano to see if there are specific requirements or workarounds for using the I2S2 interface.

  4. Hardware Verification: Given that driving each pad as a GPIO puts 3.3V on the header pin, it suggests that the hardware (pads and traces) is functional. However, the absence of any signal in I2S2 mode indicates a configuration or setup issue rather than a hardware fault.

  5. Software and Configuration: The use of a dummy codec to complete the DAI link is a good troubleshooting step. Ensure that the ALSA configuration and any other software components are correctly set up for I2S2 output.

Without direct access to the specific Jetson Orin Nano documentation or the ability to test the setup, it’s challenging to provide a definitive solution. However, based on the information provided:

  • Verify Clock and Pinmux Settings: Double-check that all clock and pinmux settings are correct for I2S2 master mode.
  • Investigate Direction-Controlled Level Translator: If such a component exists, ensure it’s properly configured for output.
  • Check for Errata or Additional Requirements: Consult official NVIDIA resources for any specific setup or configuration needs.
  • Hardware and Software Configuration: Ensure all hardware and software components are correctly configured for I2S2 output.

If the issue persists, it may be beneficial to consult the NVIDIA Jetson forums or support channels for more specific guidance or to share your findings with the community for further assistance.

— We support team will also look into your issue to have further suggestions soon. please stay tuned. —

5

I matched the exact amixer config from thread 367599 (Sample Rate 48000, BCLK Ratio 64, cbs-cfs, i2s, S32_LE); the stream runs OK but BCLK (pin 12), FS (pin 35) and DOUT (pin 40) are all still Low on the scope*, while the same pads drive 3.3 V driven as GPIO outputs. *
So this doesn’t seem to be amixer config or the TXB0108 translator, my guess is the SoC pad isn’t driving in i2s2/SFIO mode on L4T R39.2

7

Hi,

Thank you for the details. The registers and clocks look correct, so this points to the pad not being switched to SFIO (I2S2) mode in the pinmux overlay.

Please refer to the 40-pin GPIO Expansion Header section in our BSP doc for the correct pinmux and Jetson-IO overlay setup:

Thanks

8

Hello @akunkulagunt,

Currently I am not attaching a real codec yet. I only want to get the I2S2 master clocks (BCLK / FS / MCLK / DOUT) out on the 40-pin header so I can read them with an oscilloscope. To make the I2S2 backend active without hardware, I bind a dummy spdif-dit codec. So I follow the custom-codec guide steps 1–5 (device-tree side, including the required link-name); steps 6–7 do not apply — I use the built-in spdif-dit dummy, not a new codec chip, and neither step generates BCLK/FS.

I followed the r39.2 “40-pin GPIO Expansion Header” + custom-codec guide step by step. Commands and output below.

  1. The audio pins are set to I2S2 (SFIO), not GPIO:
    $ sudo cat /sys/kernel/debug/pinctrl/2430000.pinmux/pinmux-pins | grep -iE ‘gpio4[124]’
    pin 50 (SOC_GPIO41_PH7): (HOG) function i2s2 group soc_gpio41_ph7
    pin 51 (SOC_GPIO42_PI0): (HOG) function i2s2 group soc_gpio42_pi0
    pin 53 (SOC_GPIO44_PI2): (HOG) function i2s2 group soc_gpio44_pi2
    Pin config registers confirm the output driver is on (bit4 = 0 = not tristated):
    $ sudo busybox devmem 0x02434088 # SCLK
    0x00001005
    $ sudo busybox devmem 0x02434090 # DOUT
    0x00000005
    $ sudo busybox devmem 0x024340A0 # FS
    0x00001005

  2. DAI link is complete in the live device tree (incl. the required link-name):
    $ ls /proc/device-tree/spdif-dit-i2s2/port/endpoint/
    bitclock-master frame-master link-name mclk-fs remote-endpoint
    $ cat /proc/device-tree/spdif-dit-i2s2/port/endpoint/link-name
    i2s2-dummy-playback
    I2S2 is set as bit-clock + frame master (bitclock-master/frame-master → the I2S endpoint).

  3. Route the audio and set I2S2 as master:
    $ amixer -c APE cset name=‘I2S2 Mux’ ‘ADMAIF1’
    $ amixer -c APE cset name=‘I2S2 codec master mode’ ‘cbs-cfs’
    $ amixer -c APE cset name=‘I2S2 codec frame mode’ ‘i2s’

  4. Play a test tone (raw ALSA, 48 kHz, S32_LE) — streams cleanly, no underrun:
    $ speaker-test -D hw:1,0 -c 2 -r 48000 -F S32_LE -t sine
    Stream parameters are 48000Hz, S32_LE, 2 channels

  5. While it plays, the controller is an enabled 32-bit master and the clocks run:
    $ sudo cat /sys/kernel/debug/regmap/2901100.i2s/registers
    80: 00000001 # I2S_ENABLE = 1
    a0: 00000407 # I2S_CTRL = master, 32-bit
    a4: 0000001f # I2S_TIMING

$ sudo cat /sys/kernel/debug/clk/clk_summary | grep -iE ‘i2s2|pll_a’
pll_a 1 1 0 245759765 # PLLA on, 245.76 MHz
i2s2 1 1 0 3071997 # I2S2 clock on, 3.072 MHz

Results: with the tone playing, a logic analyzer on the header reads 0 Hz / flat on all four lines (MCLK pin 7, SCLK pin 12, FS pin 35, DOUT pin 40), even with the threshold lowered to 0.3 V. The same pins give a clean 3.3 V when set as plain GPIO.

Questions:

  1. With the pinmux confirmed as I2S2 and the clock confirmed running, what else in the SFIO path could keep the I2S2 output off the pad?
  2. Is there a SoC-side (1.8 V) test point before the carrier’s TXB0108 translator, so I can tell a translator problem from a pad problem?
  3. Do you have any suggestion or command request I can try?

My board: NVIDIA Jetson Orin Nano Engineering Reference Developer Kit (Super) · L4T: R39 (rev 2.0) — JetPack 7 · GCID 45755727

Thank You and best regards!

9

Resolved — thanks all.

It turned out to be my device-tree overlays, not the SoC/translator. I had been driving I2S2 with a hand-built jetson-io pinmux overlay plus a custom dummy-codec overlay. Switching to NVIDIA’s shipped, tested overlay for this board fixed it immediately:

/boot/tegra234-p3767-0000+p3509-a02-audio-adafruit-uda1334a.dtbo