I2S with MCLK input

[carsonkpoly]

I'm working with TI PCM1802 ADC, which needs an MCLK/SCLK signal at a frequency multiple of fs. Why is the MCLK functionality only available to I2S output? Is there any way to enable MCLK for input I2S as well?

[earlephilhower]

No reason other than nobody thought it would be needed.

Can you try removing the _isOutput check here

arduino-pico/libraries/I2S/src/I2S.cpp

Line 137 in 5678bb9

if (_running || !_isOutput) {

and seeing if that makes things work for you? If so, please do make a PR so we can get it into the core.

[DragRedSim]

I can confirm that removing this check works (after deleting the pre-cached I2S.cpp.o and I2S.cpp.d [I think they were] files). My use case is simply to provide the MCLK to use the Pico with a PCM1808 ADC module, which requires an external master clock at a minimum. Now I've got a signal, just need to figure out how to send it back as a line input over USB...

[frohro]

Hi @carsonkpoly and @DragRedSim,
I am trying to follow in your footsteps. I have the following hookup diagram (actually using a CJMCU-1808 module) using GP0-3 like this schematic:

and my code looks like this:

#include <I2S.h>

I2S i2s(INPUT);

void setup() {
  Serial.begin(115200);

  i2s.setDATA(2);
  i2s.setBCLK(0); 
  i2s.setMCLK(3);
  // Note: LRCK pin is BCK pin plus 1 (1 in this case).
  i2s.setBitsPerSample(32);
  i2s.setFrequency(8000);
  i2s.setMCLKmult(256);
  
  i2s.begin();

  while (1) {
    int16_t l, r;
    i2s.read16(&l, &r);
    Serial.printf("%d %d\r\n", l, r);
  }
}

void loop() {
  /* Nothing here */
}

I am getting the clocks on the correct pins. The MCLK pin is not quite at the right frequency. The datasheet says it needs to be synchronous with the other clocks, so this might be a problem. Here is the quote from the datasheet: "In slave mode, the PCM1808 device operates under LRCK (pin 7), synchronized with system clock SCKI (pin 6). The PCM1808 device does not require a specific phase relationship between LRCK and SCKI, but does require the synchronization of LRCK and SCKI." The datasheet goes on to say: "If the relationship between LRCK and SCKI changes more than ±6 BCKs for 64 BCK/frame (±5 BCKs for 48 BCK/frame) during one sample period due to LRCK or SCKI jitter, internal operation of the ADC halts within 1 / fS and digital output goes to zero data (BPZ code) until resynchronization between LRCK and SCKI occurs." It isn't off enough to trigger the RESET for the PCM1808. It appears to be off by about half a BCK bit if my calculations are correct. The MCLK is 2.0813 MHz and the BCK is 515.504 KHz. Here is a photo of my scope probing those.

The BCK and LRCK are nicely in phase. The LRCK is 8.0545 kHz. See this photo.

I am getting no data on the DOUT pin. It is just flat. The shows all zeros too.

MD0, MD1, and FMT have all been verified to be low.
Do you have any suggestions?
Thanks!

[carsonkpoly]

How are you physically wiring the connections from the pi to the ADC? If your traces or wires connecting them are too long you might need some terminating resistors (47 ohms or so). You also probably should change the pi's clock frequency so that it evenly divides to the correct MCLK frequency. You can do this with

i2s.setSysClk(sample_rate);

One last thing to check as well, pretty sure the API is configured to have the pi output 48 BCLK/frame which would need to change

i2s.setMCLKmult(256);

to

i2s.setMCLKmult(384);

From PCM1808 datasheet:
7.3.5.1.2 Slave Mode
In slave mode, BCK and LRCK work as input pins. The PCM1808 device accepts 64-BCK/frame or 48-
BCK/frame format (only for a 384-fS system clock), not 32-BCK/frame format.

Hope this helps.

[frohro]

Thank you so much @carsonkpoly for your gracious reply. The leads are fairly short.

Your advice on i2s.setSysClk(8000); solved my synchronization issue with MCLK and BCK. Thank you so much for that tip.
Unfortunately I am still getting no data on the data pin. I did change the bits/sample and BCK multiplier as you suggested. Here is my present code:

#include <I2S.h>

I2S i2s(INPUT);

void setup() {
  Serial.begin(2000000);

  i2s.setDATA(2);
  i2s.setBCLK(0); 
  i2s.setMCLK(3);
  // Note: LRCK pin is BCK pin plus 1 (1 in this case).
  i2s.setBitsPerSample(24);
  i2s.setFrequency(8000);
  i2s.setMCLKmult(384);
  i2s.setSysClk(8000);
  
  i2s.begin();

  while (1) {
    int32_t l, r;
    i2s.read24(&l, &r);
    Serial.printf("%d %d\r\n", l, r);
  }

I have tried all kinds of different sample rates and bits/sample, but nothing brings up data on the data pin. All the power supplies have been measured to be correct. I'm still scratching my head, but at least my clocks are now synchronized.

[frohro]

Thanks @carsonkpoly, my problem turned out to be a cold solder joint.

[frohro]

@carsonkpoly and @earlephilhower, I have another question, because the data I am getting is not what I expect. I am putting a sinewave of 1000 Hz, 2V peak to peak in the left analog input (nothing connected to the right one). Using the following code:

#include <Arduino.h>
#include <I2S.h>

I2S i2s(INPUT);

void setup() {
  
  int i;
  int32_t l[1000], r[1000];
  
  Serial.begin();

  i2s.setDATA(2);
  i2s.setBCLK(0); 
  i2s.setMCLK(3);
  // Note: LRCK pin is BCK pin plus 1 (1 in this case).
  i2s.setBitsPerSample(24);
  i2s.setFrequency(48000);
  i2s.setMCLKmult(384);
  i2s.setSysClk(48000);
  i2s.setBuffers(32,0,0);
  
  i2s.begin();

  delay(10000);
  for(i=0; i<500; i++) {
    i2s.read24(l, r);
  }
  for(i=0; i<500; i++){
    Serial.printf("%d %d\r\n", r[i], l[i]);
  }
}

void loop() {
  /* Nothing here */
}

I get this data.

I made two separate loops in case the Serial.printf() was slow. A 32-bit int in 2.14e9, so the scale is about what I expect. If I disconnect the sinewave, I get something similar.

I can see the sinewave at the PCM1808 pin 13 when it is connected.
Any ideas as to the solution to this puzzle?

[Andy2No]

i2s.setBuffers(32,0,0);

https://github.com/earlephilhower/arduino-pico/blob/master/docs/i2s.rst says;

bool setBuffers(size_t buffers, size_t bufferWords, int32_t silenceSample = 0)

Set the number of DMA buffers and their size in 32-bit words as well as the word to fill when no data is available to send to the I2S hardware.

so try;

i2s.setBuffers(32, 1000, 0);

though I'm not sure if there's enough RAM for that many buffers, so maybe try a smaller number for the first parameter, but perhaps keep the second one, bufferWords, as 1000... or maybe 2000, since it says that's the number of 32 bit words, not the number of samples?

I'm not at all sure how to choose the number of buffers, and there doesn't seem to be enough information to go on to decide how to choose their size, but setting the size to zero seems wrong.

[Andy2No]

Also, though not directly related to the data you're showing, are you sure the input voltage is in the allowed range?

From the TI datasheet:

VINL, VINR, VREF
Analog input voltage
Min –0.3
Max (VCC + 0.3 V) < 6.5V

Since your connection picture shows RCA/phono sockets wired to the i2s module, it looks like you might feed it an audio signal that can be positive or negative with respect to ground, which is not what that chip wants. Maybe decouple the inputs with capacitors in series between the RCA sockets and the input pins, and bias the inputs to Vcc/2 with two resistors - one to ground and one to Vcc. The analog input impedance of the chip is 60kΩ, according to the datasheet, so maybe try 100k or 1M for the two bias resistors, and decoupling capacitors somewhere in the range of 1uF to 2uF.

You can get non-polarised electrolytic capacitors or MLCC (multilayer ceramic capacitors) in that range, though it seems common to use an electrolytic capacitor with the + facing the socket.

[frohro]

Thanks, @Andy2No for the insights. The voltage is in the range. There is a capacitor in between the input and the PCM1808, and the DC voltage at this input pin is 2.5 V. I'm not sure where you saw RCA plugs. Maybe you thought the capacitors on the Chinese module were RCA/phono sockets.

I guessed on the setBuffers(), so I was hoping your idea there was right, but with this code, it did no better.

#include <Arduino.h>
#include <I2S.h>

I2S i2s(INPUT);

void setup() {
  
  int i;
  int32_t l[1000], r[1000];
  
  Serial.begin();

  i2s.setDATA(2);
  i2s.setBCLK(0); 
  i2s.setMCLK(3);
  // Note: LRCK pin is BCK pin plus 1 (1 in this case).
  i2s.setBitsPerSample(24);
  i2s.setFrequency(48000);
  i2s.setMCLKmult(384);
  i2s.setSysClk(48000);
  i2s.setBuffers(32,1000,0);
  
  i2s.begin();

  delay(10000);
  for(i=0; i<500; i++) {
    i2s.read24(l, r);
  }
  for(i=0; i<500; i++){
    Serial.printf("%d %d\r\n", r[i], l[i]);
  }
}

void loop() {
  /* Nothing here */
}

It fact, if I comment the setBuffers, it still looks like this.

Thanks for the ideas!

[earlephilhower]

Your sample code's got a few big problems.

  int32_t l[1000], r[1000];

That overflows the 8K stack. Make the big vars global or, better yet--don't make them at all

for(i=0; i<500; i++) {
    i2s.read24(l, r);
  }

This never actually reads into anything but l[0] and r[0]. You probably wanted

for(i=0; i<500; i++) {
    i2s.read24(l+i, r+i);
  }

But, again, better not to even do this because you can just do this since you've overflowed anyway by sleeping for 10s:

....
i2s.begin();
delay(10000);
for (int i=0; i<500; i++) {
  int32_t l, r;
  i2s.read24(&l, &r);
  Serial.printf("%d %d\r\n", l, r);
}

Also,

i2s.setBuffers(32,1000,0);

makes 32 separate 1000-word buffers. That's enormous and really unnecessary.

i2s.setBuffers(16, 64, 0);

would give you a buffer of 1K samples before overflow.

[frohro]

Thanks so much for the pointers @earlephilhower . Thanks for letting me know the stack size. That is helpful.
The delay(10000) was to give me time to open the serial plot window before the data was all written. :-) There is something I need to learn here. I was increasing the buffer size because I saw you recommend that to someone else earlier. I don't understand the docs when they say,

bool setBuffers(size_t buffers, size_t bufferWords, int32_t silenceSample = 0)

Set the number of DMA buffers and their size in 32-bit words as well as the word to fill when no data is available to send to the I2S hardware. Call before I2S::begin().
What are the benefits of more buffers, and what are the benefits of a larger buffer size (bufferWords)?

The reason I was making an array to save the data was to try and prove to myself that the Serial.printf() wasn't too slow for my 48000 Hz sample rate. Here is what it looks like as the example program suggests, printing as the data comes in.

Note: The right channel is almost always negative and was when the 1000 Hz 2V amplitude sinewave was on the right channel. If I switch it to the left, I get this:

and here is the code that produces these plots.

I2S i2s(INPUT);

void setup() {
  
  int i;

  Serial.begin();

  i2s.setDATA(2);
  i2s.setBCLK(0); 
  i2s.setMCLK(3);
  // Note: LRCK pin is BCK pin plus 1 (1 in this case).
  i2s.setBitsPerSample(24);
  i2s.setFrequency(48000);
  i2s.setMCLKmult(384);
  i2s.setSysClk(48000);
  i2s.setBuffers(64,16,0);
  
  i2s.begin();
  while(1) {
    int32_t l, r;
    i2s.read24(&l, &r);
    Serial.printf("%d %d\r\n", l, r);
}

}

void loop() {
  /* Nothing here */
}

I did indeed want i2s.read(r+i, l+i). Thanks for catching that.

I still think the data is not coming in the format I think it should be. Here is what I got when running this code:

#include <Arduino.h>
#include <I2S.h>

I2S i2s(INPUT);

int32_t r[500], l[500];

void setup() {

  Serial.begin();

  i2s.setDATA(2);
  i2s.setBCLK(0); 
  i2s.setMCLK(3);
  // Note: LRCK pin is BCK pin plus 1 (1 in this case).
  i2s.setBitsPerSample(24);
  i2s.setFrequency(8000);
  i2s.setMCLKmult(384);
  i2s.setSysClk(8000);
  i2s.setBuffers(64,16,0);

  i2s.begin();

//  while(1) {
//    int32_t l, r;
//    i2s.read24(&l, &r);
//    Serial.printf("%d %d\r\n", l, r);
//}

}

void loop() {
  int i;
  for(i=0; i<500; i++) {
    i2s.read24(l+i, r+i);
  }
  for(i=0; i<500; i++){
    for(i=0; i<500; i++){
      Serial.printf("%d %d\r\n", l[i],  r[i]);
  }
}

Notice how the red trace is now always negative. The input sinewave was on the left. When I change it to the right, I get this:

It does appear changing from left to right has the expected effect, but both channels seem to have something wrong in the way the bits are interpreted.

I have MD0, MD1 and FMT disconnected, and the docs say that is low due to pull down resistors. The MOD pins indicate it should be in slave mode, and it certainly looks like it is. The FMT pin being low should be regular I2S 24-bit. If it is high, it is left justified 24-bit.

Again, thanks so much for the assistance!

[frohro]

@earlephilhower I am continuing to work on this, and so looked at the code for read24, and then tried read32 which shows the results before shifting left by 8 bits. I get this kind of thing.

Note that 2^23 is 8.388e6 which is about where the right channel is peaking out so consistently.
It almost seemed to me that perhaps the shift value wasn't right, so I played around with it and got something working a little better, but still not quite right by shifting over 9 bits. Here is what it looks like with input on the left channel at 100 Hz and 300 mV amplitude.

Note: If you take the amplitude of about 3.5e8 and divide by 2^31 and multiply by 2.5, you get about 400 mV, which is close to the 300 mV I think I have. If you look at the right channel, you find it is not working quite right either. Here is what happens if I connect the same wave to the right channel instead of the left.

I can see the sinewave in it and if I adjust the DC offset up and down a good sinewave appears or sometimes a clipped one appears. I measure the DC offset at the PCM1808 pin 14 (in steady state with me leaving the DC offset on the signal source alone) and it is the same as the other channel (pin 13) and 2.4 volts.

Here is the code for this:

#include <Arduino.h>
#include <I2S.h>

I2S i2s(INPUT);

int32_t r[500], l[500];

void setup() {

  Serial.begin();

  i2s.setDATA(2);
  i2s.setBCLK(0); 
  i2s.setMCLK(3);
  // Note: LRCK pin is BCK pin plus 1 (1 in this case).
  i2s.setBitsPerSample(24);
  i2s.setFrequency(8000);
  i2s.setMCLKmult(384);
  i2s.setSysClk(8000);
  i2s.setBuffers(64,16,0);

  i2s.begin();

//  while(1) {
//    int32_t l, r;
//    i2s.read24(&l, &r);
//    Serial.printf("%d %d\r\n", l, r);
//}

}

void loop() {
  int i;
  for(i=0; i<500; i++) {
    i2s.read32(l+i, r+i);
  }
  for(i=0; i<500; i++){
    for(i=0; i<500; i++){
      Serial.printf("%d %d\r\n", l[i]<<9,  r[i]<<9);
  }
}

}

Thanks for all your help!

[Andy2No]

I may well be misunderstanding, but it seems you should be shifting by 8 bits, not 9. I assume this is just to get the sign bit in the right place. From the arduino-pico/docs/i2s.rst documentation:

Note About 24-bit Samples

24-bit samples are stored as left-aligned 32-bit values with bits 7..0 ignored. Only the upper 24 bits 31...8 will be transmitted or received. The actual I2S protocol will only transmit or receive 24 bits in this mode, even though the data is 32-bit packed.

I don't understand how to go about choosing the number of buffers or the buffer size either. I can see how double buffering could help, for reading in real time out of sync with the i2s transfer, but I'm not clear why lots of little buffers is better than two larger ones.

[Andy2No]

Looking at one of those diagrams again, that doesn't seem right. In the TI TLV320... one above, the LSB is read on the rising edge of BCK, then LRCK changes on the next falling edge of BCK, for the left channel. You seem to have LRCK changing early, as the LSB is being read on the rising edge:

    jmp x--, left    side 0b00
    in pins, 1       side 0b11 ; Last bit of left has WCLK change per I2S spec
    mov x, y         side 0b10

To match that diagram, it looks to me like that change of LRCK needs to be delayed, like this:

    jmp x--, left    side 0b00
    in pins, 1       side 0b01 ; !! Keep LRCK low until the next trailing edge of BCK
    mov x, y         side 0b10

Similarly at the end of the right channel. It looks like you need to do the move on the rising edge of BCK but keep LRCK as it is, until the next trailing edge of BCK

right:
    in pins, 1       side 0b11
    jmp x--, right   side 0b10
    in pins, 1       side 0b01 ; Last bit of right also has WCLK change
    ; Loop back to beginning...

Becomes:

right:
    in pins, 1       side 0b11
    jmp x--, right   side 0b10
    in pins, 1       side 0b11 ;   !! delay WCLK change to next falling edge of BCK
    ; Loop back to beginning...

[frohro]

@Andy2No, thanks for thinking about this for me! The TLV320 timing diagram is different than the PCM1808 diagram. The TLV320 is a DAC and the PCM1808 is an ADC (what I'm using). The main differences to me are that extra unnecessary bits are swapped relative to the data and they change the numbers assignned to the bits. (One has MSB as 0 and one has MSB as 24.) Here are the two timing diagrams.


I am certain it would not be hard to do the shift in the PIO, but I want to understand why the extra bit shift is necessary, and I guess I'm dense, but I still don't see why the PIO code is wrong as it is in my previous comment. I believe looking at different datasheets is part of the reason why we disagree on how the PIO should be. @earlephilhower, maybe you could give us your opinion. @earlephilhower, I am also wondering about the AudioBufferManager class. It looks like it was created the same time as the I2S library, and if my understanding of the PIO code is correct, it would perhaps be the next place to look for the solution to this mystery. Can you give me an idea how well tested input is with the I2S library, and the AudioBufferManager? How were these tested? Where do you think the best place to look for the explanation of the extra bit I have to shift would be?

[Andy2No]

@frohro The way I read that PCM1808 diagram is that LRCK should not change state until at least the next trailing edge of BCK after bit 24 is clocked in (on the rising edge).

The fact that you need to shift the result left indicates that you've lost one bit of input, and since you don't seem to have lost the sign bit (it can be recovered by shifting - it's just misaligned), you've evidently lost bit 24.

i2s input was the last part to be added, and I think you've tested it more thoroughly than anyone else. Also, some devices may be more forgiving of timing than others. This one appears to need a minimum hold time after the rising edge. Perhaps the other device it was tested with didn't.

[Andy2No]

Not directly related, but possibly useful to anyone trying similar i2s ADCs, as a ready made module, I found this page about a common design flaw and how to work around it - a flaw in the commonly available modules, not the chips, but affecting selecting the format:

https://www.pjrc.com/pcm1802-breakout-board-needs-hack/

That's about the PCM1802, but it's a fair bet that PCM1808 modules are also made/sold by the same companies, and may have similar confusing issues.

[frohro]

@Andy2No, I checked both continuity between FMT on the board and pin 12, the FMT pin, and the voltage level on Pin 12 with the power on, and both confirm that the board I have does not have the problem the PCM1802 board does. I concur that I may be losing the LSB bit, in the 24-bit mode and maybe the 32-bit mode.

I think you have nicely pinpointed where our difference in interpretation of the data comes about when you say,

The way I read that PCM1808 diagram is that LRCK should not change state until at least the next trailing edge of BCK after bit 24 is clocked in (on the rising edge).

When I look at the timing diagram, here is what I think it says and why.

• I think we are both looking at the 24-bit way of reading data, not the 32. Let's assume that format.
• There are 24 bits that must be sent each half cycle of the LRCLK and the frequency of BCK is 24 times the frequency of LRCK.
• The first cycle of the BCK after the LRCK changes does not have data from the 24 bits that will be sent in that half cycle. What it contains is the question.
• Therefore, the first BCK cycle after the LRCK changes contains the LSB of the data from the previous 24 bits of a measurement.
• The timing diagram does not show that explicitly, because it is also supposed to show what happens when we use the 32-bit way of sending data, and the last eight bits sent are 00000000, so it shows that at low.

Thank you so much for the information about how much testing has been done on the I2S input case. Knowing that is so valuable. I was suspicious. I would like to get this figured out, so those who come after us have an easier time of it. :-)
I too have wondered if I am losing the LSB of data. At this point, I'm just not sure. I am also worried about glitches as seen in the 24-bit format plot above. They worry me even more than losing the LSB. I'm still not sure what the best way to test this all is.

Perhaps the next thing I will do is send the data in a binary way to the host so I don't have the discontinuities coming from restarting plotting my next array. It should be a step in the direction I want to go and also should make glitches more apparent when I plot or otherwise examine a lot more of the data at once.

Thanks for thinking about this with me. I am not very fluent in C++ and certainly not in PIO code, but I do have hardware here I can test with. @earlephilhower, I would be happy to have Amazon send you one of these PCM1808 boards if you would like to be able to test the hardware too. :-)

[Andy2No]

I can't tell which trace is blue and which is green, but if BCK is the shorter one / lowest signal, with four pulses shown, then yes, that looks inverted. The timing diagram shows BCK changing from high to low as LRCK changes state (either way) in both formats, so even if LRCK was inverted, what your scope shows still doesn't match the diagram.

I can't tell from that whether the data is being left justified or not. If you could do it again with negative inputs that would make it clearer - the MSB would then be set, making it clearer where the data starts. Even so, It seems more likely that clocking the data on the wrong edge of BCK, because it's inverted, is the problem.

[frohro]

@Andy2No
Yes, the tallest trace (yellow) is LRCK. The middle trace (green) is data, and the bottom trace (blue) is BCK. There is a link in my posting above that gives other pictures. It appears you figured the colors out correctly.