Jetson Nano I2S stopped working on two devboards


Hi all

I have already contacted you regarding problems with I2S.
(Persist Alsa configuration (I2S4) in Jetson Nano doesn't apply upon reboot - #30 by mkumard)

In fact, the solution to the problem then was to buy a new devboard. But today, when working with this new board, I2S stopped working again.
Here is the sequence of actions that led to this:

  • run the arecord command
  • an error occurs (arecord: pcm_read: 2103: read error: Input/output error)
  • run the arecord command
  • repetition of error (arecord: pcm_read: 2103: read error: Input/output error)
  • run speaker test (no results)
  • rebooted the device
  • run speaker test (no results)
    — connected the oscilloscope probes to the contacts (there is no activity on the I2S lines)

I am writing to you because this is already the second devboard. Before this, the audio worked and there were no hotswaps with contacts.

Best regards, Georgiy

Hi georgiy,
Can I know did you connected any external board or codec to the I2S line during this test. Just to understand if any external board is interfering with the I2S voltage levels.

Can you update complete commands used for your testing

Hi @mkumard

EVAL-ADAU1787Z was connected to the Jetson nano development board. Here is a link to the board description (

Here is the full version of the recording command:

$ arecord -D hw:tegrasndt210ref,4 -r 48000 -f S16_LE -c 1 rec.wav

Here is the complete command for the speaker test:
speaker-test -D hw:“tegrasndt210ref”,4 -r 48000 -c 2 -F S16_LE -t sine -f 1000


I like to understand before you connected EVAL-ADAU1787Z board, did you checked the I2S clock signals out of Jetson nano board?

I hope you configured Jetson io tool to enable the I2S4 pinmux ?.

Try with below command and let me know if you hit pcm_read error
amixer -c “tegrasndt210ref” cset name=“ADMAIF5 Mux” “I2S4”
arecord -D hw:tegrasndt210ref,4 -r 48000 -f S16_LE -c 2 rec.wav

Hi @mkumard

There may have been a misunderstanding. I have completed all the setup and have a working setup. The problem is not in the setup; the board has already been in operation and all signals and settings have been checked. The problem is that for some reason the I2S4 interface on the Jetson Nano module stops working. This is definitely not due to the settings, as I double-checked everything on other images. In this topic (Persist Alsa configuration (I2S4) in Jetson Nano doesn't apply upon reboot - #32 by mkumard) we carried out all the tests to figure out why the interface stopped working and as a result, only buying a new board helped. Now this is the second board that has stopped working. Changing settings or image does not help.


The 40 pin io header on the Jetson Nano has 3.3V levels. The EVAL-ADAU1787Z board uses 1.8V levels by default. This simply doesn’t match and may cause hardware damage.

The level shifters (TXD0108) on the NVidia devkit carrier board are rather weak. I suggest using 74AVC_T (eg 74AVC4T774) voltage translating buffers between the two boards.

next checkpoint: ground loops

then: use ESD protection. The Eval Board does not have any and seems to be somewhat sensitive. It is not meant to be used as a finished product.

Check with an oscilloscope for damage on the I2S lines and make sure that all signals meet their specifications.

1 Like

Hi @fchkjwlsq

Thanks for the quick response.

Let’s start with the fact that Jetson works in master mode. Non-harmonization of levels is much more likely to result in incorrect data detection. The connection of these boards worked and was tested. In addition, the version with level mismatch does not work for the first case in which the I2S interface died when working with the MAX98357 module.
In addition, the MAX98357 and EVAL-ADAU1787Z modules remained fully operational. On Jetson Nano modules there is no activity on the I2S lines (no clocking either).


If your problem is the Jetson Nano Devkit, then swap U48 (TXB0108RGYR). This is the level shifter I2C on the carrier board responsible for the I2S on the 40 pin header. Then both boards should work again. The processor modules should be unaffected.

You really should use buffers between Jetson Carrier Board and I2S Codec board. These TXB0108 are rather sensitive and easy to upset.

1 Like

Hi Frank and Nvidia. Thanks for the reply it’s super appreciated. Just to give some color on the project. We’re using the dev kits while we’re testing out components for the custom board. Georgiy and you guys know better than me but my question is do you recommend specific buffer’s / regulators that would be recommended for our custom board and the adua1787 chip?

Jetson Nano DevKit and Modules are End Of Life. You can buy the modules till 2027 but you won’t get any updates any more since both the Jetpack and Ubuntu 18.04 are out of support. You really should use Orin Nano.

For buffer chips:

These have 4 channels, and you can switch direction of each channel independently. Common Output Enable.

This is a newer version with wider voltage range (0.65V instead of 0.8V)

2 groups of 2 channels each, Direction and Output Enable for each group.

Each side has its own power supply.

Thanks @fchkjwlsq Is there a module that matches the size of the nano module. Otherwise this is a major rewrite as of right now.

We are aware of this issue, but thanks for the advice.

Thanks for the recommended logic level converters.

I also wanted to ask. Is there a 40-pin connector on the board, test points through which you can see the signal in front of the TXB0108RGYR chip? I might check the clock while we look for a replacement TXB0108RGYR.


The other side goes straight to the SODIMM module socket (1.8V level).

Orin Nano and Orin NX are mechanically identical (different cooler though!), and the pinout is about 70% identical.
(-) only HDMI/DP1, no HDMI/DP0
(-) only 4 CSI2 channels instead of 6
(-) no SDIO/SDCARD/EMMC support
(+) two more USB3 SS
(+) one more PCIe x2 or two PCIe x1
(+) much higher performance, more RAM (optional)
(!) NVMe SSD required as storage for production modules as these don’t have EMMC any more
(+) available till 2030, Ubuntu 22.04 OS support guaranteed until 2027/04 (5 years from release date)

Another remark: The TXB0108 level shifer ICs (there are 3 on the devkit carrier) have a special feature where the ic figures out the direction of each signal on its own. The processor itself has registers for each pin to determine pin function (GPIO or peripherial function), direction (input/output) and pullup/pulldown. The level shifter don’t get these setting, so NVidia needed to use level shifters with automatic direction control.

Don’t use these chips on your custom board unless you absolutely need to and you know what you are doing. The outputs are rather weak, and the auto direction control can easily mess up if there is too much capacitance on a pin or a too strong pullup/pulldown. On your custom board the signal direction should be fixed, and you should use buffers with manual direction control (DIR pin). These are much more follproof and stronger.

There are the 74AVC-T (0.8 to 3.6V, ±8mA drive), 74ACX-T (0.65 to 3.6V, ±8mA drive) and the 74LVC-T (1.65 to 5.5V, ±24mA drive capability). There are versions with 1, 2, 4 and 8 channels in a package. These do work just fine.

Hi @fchkjwlsq

Today I decided to do a test. I launched a speaker test and decided to look at the signals on the I2S lines on the SODIMM contacts to check whether the reason was really a damaged TXB0108RGYR, but there was no pulse sequence.
This baffles me.


Does the I2C control port still work? i2cdetect should be able to detect it.

Please tell me which I2C bus number should refer to I2S(4) on the 40-pin connector.

Doesn’t using I2C refer to the external codec driver?

I found mention of i2cdetect in the documentation, but the pinmux doc does not indicate the codec or I2C for the I2S interface.

There is no fixed relationship between I2S data interface and I2C control interface. You must specify I2C bus and target address of your codec in the device tree - that is what the device tree is for, telling the system where to find each device.

Since your codec is a 1.8V device it would make sense to use I2C2 (module pins 232/234), since this I2C is also 1.8V. The others are 3.3V, so you must use a level shifter IC specifically designed for I2C (!). NVidia uses FXMA2102L8X on Orin AGX DevKit carrier.

The 40 pin header only provide I2C0 and I2C1, which are both 3.3V busses.

Wait, you’ve got me a little confused. Why would I need to use the I2C bus to use I2S. Right now I’m using a devkit. If TXB0108RGYR fails and because of this I do not see any pulses on the 40-pin connector, then I should see pulses in front of TXB0108RGYR, that is, at the output of the SODIMM.