MAX32666 PCM Audio subsystem keeps repeating samples

I think it's probably normal that 8 bits are dropped per 32 bits and set to zero in the I2S stream, if the DAC is only a 24-bit part. I've not checked the I2S spec in a while so I could be wrong. For a lot of scenarios it can be acceptable that one byte out of four is wasted, since it means easier processing on 4-byte boundaries - i.e. in the scenarios that memory isn't a concern, I wouldn't worry about the 25% waste.

However, you mention not wanting to use all pins, of which normally at least several are required for the DAC to understand the data stream pin, so I'm wondering if there is some reason you wish the stream not to output zero.. are you trying to use the I2S functionality for some other purpose other than interfacing an I2S DAC? What's the use-case and what are you planning to interface (just in case there's some alternative solution).

Yes, I understand that most I2S devices only understand up to 24 bits per sample, but the datasheet clearly says it supports 32bits word size (table 23-3)

I don't need all pins as I'm only using it to output, not capture any signal, so I thought that I could leave the DIN port in its default state (ie GPIO). But my experiments show that it MUST be configured as Alternate Function 1 for everything to work properly...

And yes, I'm trying to use this to output an arbitrary long bit sequence which base frequency is the system frequency divided by twelve. And because the divider is not a power of two, that's the only subsystem that I could find that offers to do such a division (Section 23.4.2). From what I read, the SPI subsystem cannot do that for instance.

It may be either a bug in whatever config/API code you're using, or somewhere else that 32-bit DAC also needs to be configured too. I doubt many people tested 32-bit since most DACs will probably be 16 or 24-bit, so perhaps it's a bug in their code (i.e. might need registers examining in the datasheet and perhaps configuring it manually). 

What's the actual goal, what equipment needs that bit sequence, and what is that frequency? 

Is it possibly down to all the printf debug statements wasting too much time so it can't keep up?

I thought that too, but they weren't there in the loop when I did the capture above. I only added them to try to figure out what's going on, and it did not change the result.
Here is the output with the printf:

wordIndex before saturate: 0
int_pcm_tx_status: 00000000'00000000'00000000'00000000
wordIndex after saturate: 8
int_pcm_tx_status: 11000000'00000000'00000000'00000000
8 8 8 8 8 8 8 8 12
wordIndex at end: 26
int_pcm_tx_status: 00000000'00000000'00000000'00000000

I see that it waits for a while with the buffer full, puts 4 more samples, and then no longer waits in the while loop until everything is "written" in the FIFO buffers.

The datasheet says sample rates up to 192k. That's a bit clock of 12.288MHz with frames of 32 bits. Period 81ns. Are you trying to work faster to drive your LEDs? Although you may be able to program the clock to do that, there's no guarantee the data handling and framing will play ball. I'd start with 192k, and get that working first, before trying to stretch it beyond what it was designed for.

The datasheet does not say much more than "32 bits words are supported".

The end goal is to generate a bit sequence suitable for WS281B LEDs inside the FastLED library. But it could also be outside FastLED, I'm just trying to generate the proper sequence.
Thing is, bit banging cannot work, the fastest I can turn on / turn off a single pin is 600ns for a complete cycle. And that's without any code between the two pin set instructions.
I thought about using the pulse train engine, but that's not desirable as it gets output on pins that are not routed on that board

Hence the reason I'm trying to use the Audio subsystem with a clock set at 8MHz, and it seems that I can get the proper signal, provided I make sure the read/write of samples happens quite fast:

The 1250ns per byte are there, with the expected Ton for 0 or 1 so that should work.

Well, I say should because it seems the 900mV that appear on the line before the bits are output is interfering with the level shifter that I'm using, the same one that works fine with an ESP32.

I updated the code at Github, on to chase a way to get rid of that 900mV and see if it helps

Thanks for the replies

Yeah, that's likely an issue here. After experimenting a bit more, even if it's not specified in the datasheet, it seems the FIFOs are implemented as ring buffers. This means that if the write pointer is no longer updated, the read pointer will eventually catch up to it and stop being updated as well, being stuck on the sample_count - buffer_size value, not the last one as the wording in the datasheet implies. That means I had to make sure there are enough "all zero" samples set in the buffers to make sure to get a final low level.

Well, after lots of fiddling with code, I managed to get what I want:

These are timings for 26 samples sent via I2S

And pushing even further, I was finally able to address all 64 LEDs with a nice repeating pattern:

With the first hurdle out of the way, let's move on to the next ones: BMI160, SDHC, BTLE...

I'm not sure I will manage to get everything working, but if wouldn't be a challenge if there wasn't some hair pulling involved.

Thanks for all the recommendation