Restrictions on some pins combinations for external I2S DAC ?

[martinroger]

Hi Phil,

I feel this is going to be one of those painfully obvious answers, but I have to ask because I cannot find a good explanation in the software or in the hardware references.

I am using an ESP32-WROOM-32 coming as part of one of those many devkit clones, coupled to a an Adafruit-style UDA1334 DAC. From the software and library perspective, I am using the arduino framework at 3.0.7, so to keep things nice I am relying on your AudioTools library for the I2S Stream.

At the time of writing this discussion ticket I am on those versions for this lib and for Audio-Tools :

|-- ESP32-A2DP @ 1.8.7+sha.8faaafa
|-- audio-tools @ 1.0.1+sha.b10269f

My code relies on the simple A2DP -> I2S pipeline, so the archetype looks something like that :

#include "AudioTools.h"
#include "BluetoothA2DPSink.h"
I2SStream i2s;
BluetoothA2DPSink a2dp_sink(i2s);
...
void setup() {
...
    auto cfg = i2s.defaultConfig(TX_MODE);
    cfg.pin_ws = 15; // Default is 15
    cfg.pin_data = 22; // Default is 22
    cfg.pin_bck = 14; // Default is 14
    cfg.sample_rate = 44100;
    cfg.i2s_format = I2S_LSB_FORMAT;
    i2s.begin(cfg);
...
    //a2dp_sink configuration and start() calls
}
...

With the default WSEL / DIN / BCLK pins, as per the Wiki, it works absolutely great.
Also to note, I do not have anything else connected to any pins outside of one UART on 16-17.

For practicality purposes, I wanted to shift around a bit which pins were used, and I didn't find any restrictions on which ones to use, aside from the usual ones (no SPI flash pins, no input-only pins etc). So I tried this :

...
    cfg.pin_ws = 25; // Default is 15
    cfg.pin_data = 26; // Default is 22
    cfg.pin_bck = 27; // Default is 14
...

Unfortunately, everything seems functional, debug logs don't complain about anything, but no sound comes out of the DAC except for some occasional crunch noise.
Undeterred, I tried other combinations, and got those results :

Pins	Default (OK)	OK	OK	NOK	NOK	OK	OK	NOK	NOK
WSEL	15	26	26	25	25	25	26	14	27
DIN	22	27	27	26	22	22	22	25	26
BCK	14	14	12	14	26	14	14	26	25

So clearly there is something a bit weird when trying to use GPIOs 25 and 26 together, and I suspect it might have to do with the fact that they share the onboard DAC outputs, but I cannot really find anything about that online, in the WROOM technical reference or in the library. What am I missing ?

[pschatzmann]

I am not aware of any restrictions and from my point of view 25 and 26 should work.
I would suggest to use the sine output test sketch and check the output of each pin with a oscilloscope or logical analyzer...

Maybe you fried one of those pins ?

[martinroger]

I am not aware of any restrictions and from my point of view 25 and 26 should work. I would suggest to use the sine output test sketch and check the output of each pin with a oscilloscope or logical analyzer...

Maybe you fried one of those pins ?

So... I checked with another DAC board (same chip), and also with a NodeMCU32S that I know is "good", and the results are very similar (using pins 25-26-27 as WSEL/DIN/BCLK respectively) : if I start the stream all I hear are crunches from parasitic noise coming from the ESP32.

I threw my crappy oscilloscope at it, and I noticed the following : BCLK looks correctly formed, DIN seems to output data correctly (hard to tell for sure but bits are flying) but WSEL is held high all the time.

Where this gets mysterious is that if I power up the ESP on its own, and then "live-connect" the DAC, it works correctly most of the time.
Now investigating further and going to try with the simpler sine output test check from Audio-Tools.

[martinroger]

Update : the sine test seems to work flawlessly on the same hardware, with 25-26-27, every time. Now trying to do the simplest a2dp -> i2s to understand if the issue is there.

Update : also the simplest a2dp-> i2s seems to work fine. So there has got to be something else somewhere in my code that faffs around the i2s...

[martinroger]

I think I found the answer, @pschatzmann .

Further in my code, I had to start Serial2 to run communication for an iPod emulator.
Now, if I trust the documentation of the various devKitC and clones, this should be pins 16 and 17, and it should be the end of it.
However, I noticed after some tinkering that if I did not initialise Serial2 in my code, I would get normal functionality... and after some digging into the core looking for the definition of Serial2, I found this in the HardwareSerial::begin method:

    switch (_uart_nr) {
      case UART_NUM_0:
        if (rxPin < 0 && txPin < 0) {
          // do not change RX0/TX0 if it has already been set before
          rxPin = _rxPin < 0 ? (int8_t)SOC_RX0 : _rxPin;
          txPin = _txPin < 0 ? (int8_t)SOC_TX0 : _txPin;
        }
        break;
#if SOC_UART_NUM > 1  // may save some flash bytes...
      case UART_NUM_1:
        if (rxPin < 0 && txPin < 0) {
          // do not change RX1/TX1 if it has already been set before
          rxPin = _rxPin < 0 ? (int8_t)RX1 : _rxPin;
          txPin = _txPin < 0 ? (int8_t)TX1 : _txPin;
        }
        break;
#endif
#if SOC_UART_NUM > 2  // may save some flash bytes...
      case UART_NUM_2:
        if (rxPin < 0 && txPin < 0) {
          // do not change RX2/TX2 if it has already been set before
          rxPin = _rxPin < 0 ? (int8_t)RX2 : _rxPin;
          txPin = _txPin < 0 ? (int8_t)TX2 : _txPin;
        }
        break;
#endif
    }

Where the values of SOC_RX0, SOC_TX0, RX1, TX1, RX2, TX2 expand to :

SOC_RX0 -> (gpio_num_t)3
SOC_TX0 -> (gpio_num_t)1

RX1 -> (gpio_num_t)26
TX1 -> (gpio_num_t)27

RX2 -> (gpio_num_t)4
TX2 -> (gpio_num_t)25

Now this is quite different from what can be found on the interwebs for this type of devkit :

My hypothesis is that because I was initialising Serial2 right before configuring and launching the i2s stream in my setup(), it set something wrong with pin 25 (not sure what and how though) and that explains why WSEL was held high all the time when it should have been flip-flopping. I'm not sure when things get moved in the peripheral manager to pins 16/17 for Serial2, but for sure it seems related.

For good measure now I am reassigning UART1 to pins 16/17 and not using Serial2. Everything seems to work, I just have some occasional crunching noise after pausing once, but it is not audible when it is playing and it might be because right now there are lot of wires making loops in the air between the boards.

What do you think ?

[pschatzmann]

You can define your custom pins with any Serial port with

  bool setPins(int8_t rxPin, int8_t txPin, int8_t ctsPin = -1, int8_t rtsPin = -1);

See HardwareSeria.h

[martinroger]

Yes, it is what I am doing now explicitly and it works.
For the popping sounds after pausing, I see issue #517 looks eerily similar, but the linked example to the callback usage seems down. Can you confirm where the example is ?