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:
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
