I2S not working as expected?

[marcdraco1-gif]

It might be that I've done something wrong here but I've tried the demos (to keep it simple and pain free) from the I2S examples on the library on several different 2040s (all Pi Foundation) and not a single one of them seems to produce any actual audio data.

What works:

Bit Clock: Check (following the sample rates exactly as they should)
Word/Frame Clock: Check (ditto)
Master Clock: (to my surprise) Check and ditto

What doesn't:

Audio Data: Not a dickie-bird. I've checked every single pin on the header on several different boards and the same thing happens. Signals from bit, frame and master (controller) all appear as they should. Everything else either appears as a steady state or ground as the IOs aren't being using.

Outputs are probed with an oscilloscope and I need to make sure this works before I order some physical hardware from our friends in Asia - the entire PCB is already laid out for a Pico 2040 (official) but I followed the pinning in the sketches to make sure everything was OK. Am I missing something? While I'm not "new" to I2S I am new to the Pico and perhaps it needs something to trigger data IO, although that doesn't seem to likely with demos like the square wave.

I could use an STM32 but they are less convenient, and generally run at lower clock speeds and I wanted a solution that was easy for people to assemble hence the Pico seems the obvious choice, esp. when it comes to clock speeds above a couple of MHz as signal integrity becomes a very serious issue even over comparatively short jumps.

The other thing with the 2040 (or 2350) is that it's low-cost part and I can easily mount two or more on the PCB for the final iteration.

[earlephilhower]

The I2S coming from the chip runs fine. I suggest starting with unmodified https://github.com/earlephilhower/arduino-pico/blob/master/libraries/I2S/examples/SimpleTone/SimpleTone.ino and hooking up your logic analyzer to GP20, 21, and 22 and verifying you get the square-wave tone I2S data.

Note that GP20 is not pin 20 on the PCB, in general, so make sure you use the right PCB pin for those IOs.

Once that's verified, you can move on to the hookup of your DACs. Some are PITAs like the PCM5102 modules I got from AX which need a very precise setup (and some shorting of on-board jumpers) to actually speak I2S and send analog out.

After you get that running look at BackgroundAudio or ESP8266Audio for more complex I2S stuff.

[marcdraco1-gif]

Thanks for such a quick reply Earl, appreciate it. I tried that that exact example since it was simple. There's no I2S data signal on any pin. I can track an output GPIO (if I needed to) in KiCAD from the official mapping on the module. PCBs aren't that cheap even when they're assembled in China, :/

By frequency analysis of the square waves (I don't have an LA probe for the Rigol) but I can see the signals on the Pico (which are bang on within allowable tolerance) but even without that, there should be four squares popping out on four separate pins.

I can read a bitclock, L/R clock and master clock which are the three timing signals, but no data. In this shot from my PCB the pin numbers are different but it shows that there are four signals: two for syncing the data shift registers and swapping channels respectively and a master clock. For the example I didn't change the pin numbers, just mucked around with the settings and it works like a charm.

I'll pop the exact frequencies from my tests when I get back to the bench. Not sure how clear this image is (it's a screen grab) will be but you should be able to see two sets of clock and data - six GPIOs in all - and the master which keeps everything in lockstep with the board logic.

Now please correct me if I've misunderstood something but that means if there are two interfaces running there would be 2 sets of data, four clocks plus the master. When there's just a single interface running (per the test) to my mind that means data, two data clocks and a master clock. This is where I'm confused if that makes sense (I just woke up).

EDIT (in faux French accent): "A few coffees later".

Well now don't I have a red face. I have absolutely no clue what was happening yesterday but yeah, everything now probes as it should (four data streams). I know most people hate being wrong, but it's better to be wrong and admit it than deny everything. Truthfully I have zero clue what was playing silly yesterday but I don't make a habit of filing bug reports unless I've triple checked everything (and I promise, I did). I've hit similar problems with my electronic designs with things working as expected at prototype but some of the beta testers having issues. The rather hilarious irony here is I've managed to hoist myself with my own petard.

Now back to laying out this board properly, I can only offer my apologies for being an idiot. (If anyone needs me I'll be stood at the back of the room facing the wall with my big white paper hat on. I actually hale from a time when we really did that too.)

[earlephilhower]

No worries, glad it's running now and thanks for the update.

Just to be clear, all I2S interfaces are independent and can't share pins. You could, at best, have one running mclk for your multiple dacs (since mclk has no phase relationship to the bclk) as long as everyone is at the same sample rate.

[marcdraco1-gif]

Now that's interesting Earl, thanks for that. I haven't dug far enough into the spec to know that there's no phase relationship although I guess at 256x the sample rate minimum, a leading edge isn't going to make a whole hill of beans of difference. I'm curious if you've tried a fan out to share Bclk, WS and SD to several devices at once. The capacitive load might be an issue but that could be buffered with line drivers near to the receiving chips. I remember that TTL (now I'm showing my age) sorta fell on its face if we tried to fan a single gate to 3 or more inputs. Depended on the IC of course, open collector drivers would allow for more electrical "oomph" at the expense of greater power. More current means the tiny gate capacitors charge faster but then other issues like EMC become a problem.

I've got a bunch of 16-bit devices here. If I read the spec correctly a 32-bit input needs a 16-bit left shift (auto padded with 0s if the Pico works like the 4MHz CPUs I used to program are anything to go by). Presumably the bit clock runs the shift registers so that data gets progressively shifted in, until it the WS flips to indicate the other channel. Seems to me (if there is an instruction free in the PIO store that would be far more efficient than C code). Assuming the PIOs can do a n-shift in a single cycle. If not, it renders that moot but bit shift are so common that that's probably in the silicon.

Looks like I'll have to look into the PIO ASM code so I can better understand what's going on. I might have to think for once.

A short time later...

Ahah! It's it's MSB first so a 32bit data stream can run direct into a 16 bit input. For once things might be easier than I'd imagined. I'd wrongly assumed the data would be signed. Makes more sense this way.

[earlephilhower]

For exact specs, check the RP2040 datasheet, if you really have large fanout needs. It's all CMOS to CMOS 3.3V, so the tRise/tFall will probably be the issue before absolute drive strength.

Anyway, you only need to shift 24b samples (to left-align them in 32b words). 16b samples are interleaved 2 to a 32b word and sent out nice and simply. 32b samples take 2 32b words per frame, of course. If you use the faster block-write I2s::write(void *, size_t) then just interleave your 16b values as you would expect to do, no worries. Or use I2s::write16() to send them in 1 at a time.

I2S is pretty simple here. The datasheet has a good overview but essentially think of it as a small programmable FSM that can shift out N-data bits per clock to a set of N-pins, as well as hardcoded set values to 0-5 other "sideset" pins. Those sideset pins are the bclk and lrclk/ws, and the N-data is 1-bit DOUT here. It's fed with a 32b-wide, 8 deep FIFO (which is fed by DMA). It pops a 32b value out of the FIFO, shifts the appropriate # of bits out while generating BCLK and LRCLK=0/1.

[marcdraco1-gif]

Brilliant! Thank you so much for your time and maintenance Earl. I'm still a bit clueless with more advanced C++, I appreciate the basics of objects and how they make code so much clearer but as soon as it dips into things like Polymorphism my brain polymorphs into something resembling guac and runs out of my ears. You get the idea. ;)

Turns out that when I went back to the datasheets for the relevant chips, the one I thought was a target is actually a controller so I've had to wiggle the thing around a bit. As a result I've split the board into two designs - one just went out to JLC this afternoon (I'm on GMT which also explains why I spell stuff the way I do). This can help me better understand the signalling - assuming I didn't goof anything else.

So the master clock isn't needed (or even used!) which was a massive relief. I'm quite happy designing for very fast signals now but when they have to jump between different PCBs I get chills. I'm sure you're aware of the issue. But then again, I2S was never intended for interconnects, so that's on "us" so to speak.

I'm still playing a little bit of catch up from my 1980s training (and I quit doing this at any level in the mid 80s) so that's been a baptism of fire. I've dropped a bundle trying to improve a friend's design which was almost entirely analogue into something with mixed mode on the same PCB. That bit of what I term "railtrack thinking" let me down a rabbit hole chasing problems that didn't exist because I'd missed something that breaks the project no matter what. I've witnessed this sort of thinking in professionals including (and perhaps esp.) with medical doctors and a few other scientists in various fields. The point is we get stuck in a rut and keep moving forward even though we're chasing the pot of gold at the end of the rainbow. Locked into that thinking we fail to see other solutions. I remember a programming guru from my era (famous name that I've suddenly forgotten) who documented his experience with a similar problem and the catharsis that washed over when he spotted it.

Moving to an I2S capable digitiser was a light-bulb moment. Simpler, lower BOM cost and probably better performance. The next leap will use your library with a Pico (although an ESP32 or even some STM32s will work) so that I can make a dummy target to supply the existing 16-bit master which is uses a PLL to generate the internal clocks (badly). Had I looked at this two years back I'd have already have sorted this problem. Oh well, I live and learn.

BTW, I looked at your state machine code. It's very instructive in how to make code readable. I've hand coded Z80 assembler to machine code but looking at that made me blush. Words like elegant and beautiful come to mind. It just reads like a book.