Actions
Forum Thread Details
  • Replies 10 replies
  • Subscribers 466 subscribers
  • Views 182 views
  • Users 0 members are here
Related

MAX32666 PCM Audio subsystem keeps repeating samples

obones

Hello,

In an attempt at exploring the MAX32666 feature set, I'm trying to get its Audio subsystem to output a stream of bit patterns via I²S. Reading the documentation, and because the entire system is a 32bit architecture, I thought that I could use two 32 bits channels on a 64 bits frame so that no space is wasted in RAM.

Sadly, this does not to work as the lowest 8 bits are always cut out, which I reported at Analog's forums. A simple workaround is to use two 24 bits channels on a 48 bits frame so that all bits are packed without dead time in between samples.

With that out of the way I created my target samples and sent them along but could only get 900mV on the DOUT pin! As it turns out, one has to activate all four Audio pins even if you don't use them, but that's not indicated in the datasheet.

Sadly, even after that, I could not get the proper signal that I expected so I decided to create a set of samples that would allow me to clearly see what's happening on the output:

sample indexes left right
0 - 1 10000000'00000000'00000110'00000000 10000000'00000000'00001010'00000000
2 - 3 10000000'00000000'00010010'00000000 10000000'00000000'00100010'00000000
4 - 5 10000000'00000000'01000010'00000000 10000000'00000000'10000010'00000000
6 - 7 11111111'11111111'11111010'00000000 11111111'11111111'11110110'00000000
8 - 9 11111111'11111111'11101110'00000000 11111111'11111111'11011110'00000000
10 - 11 11111111'11111111'10111110'00000000 11111111'11111111'01111110'00000000
12 - 13 11111111'11111110'11111110'00000000 11111111'11111101'11111110'00000000
14 - 15 11111111'11111011'11111110'00000000 11111111'11110111'11111110'00000000
16 - 17 11111111'11101111'11111110'00000000 11111111'11011111'11111110'00000000
18 - 19 11111111'10111111'11111110'00000000 11111111'01111111'11111110'00000000
20 - 21 11111110'11111111'11111110'00000000 11111101'11111111'11111110'00000000
22 - 23 11111011'11111111'11111110'00000000 11110111'11111111'11111110'00000000
24 - 25 11000000'00000000'00000010'00000000 10000000'00000000'00000010'00000000

The basic idea is to have a marker bit be at a different place in all samples to easily identify them, while having the lowest 8 bits at zero as they will get ignored.

The code that sends all those basically does this:

Activate Audio subsystem
Turn off both TX channels
Fill transmission FIFOs (this consumes 2*4 samples)
Turn on both TX channels
While there are samples remaining, wait for space in FIFOs, place one sample for left, one for right in their respective FIFO
Now that all samples are in the FIFOs, wait for them to get empty
Turn off both TX channels

Using the "capture to file" feature of my DSO (thanks again E14, it's really a nice one), and a bit of editing in Paint.Net, I'm getting the following trace on the output pin:

image

So, the 8 queued samples are sent just fine, then an additional 4 as well, but after that, the subsystem keeps repeating samples 4 and 5 until I turn off the TX channels, for no reasons that are obvious to me.

I understand that the subsystem will repeat the last sample it has received if I'm not providing new samples fast enough, but I'm sure they are all placed in the FIFO as the while loops exit. And why repeat #4 and #5 when clearly 6 others have been given (and sent) afterwards?

In the Audio subsystem example provided in the MSDK, they are using the interrupt vector which I'll try using over the week-end to see if it helps.

In the meantime, does this situation sound familiar to any of you? Would you have any recommendation?

Thanks in advance

Parents

  • 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).

  • in reply to shabaz

    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.

  • in reply to obones

    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? 

Reply
  • in reply to obones

    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? 

Children
  • in reply to shabaz

    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:

    image

    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