TAS2563: TAS2563: Register settings for 48kHz 24 bits - mono out, 2x stereo in (PDM) - Wrong Endianess

Hi Jeff McPherson,

thank you for your reply.

But if the data stream is correct and intended in this way, how do I record usual .wav files?

If I record a file with the command arecord -f dat test.wav (equals to 16 bits 48000 Hz Stereo), I get a distorted file with wrong byte order.

Here are my device tree settings:

/ {
sound_tas2563: sound-tas2563 {
status = "okay";
compatible = "simple-audio-card";
simple-audio-card,name = "DPP-LMB-AR Soundcard TAS2563";
simple-audio-card,format = "i2s";
simple-audio-card,bitclock-inversion;
simple-audio-card,frame-master = <&tas2563cpu>;
simple-audio-card,bitclock-master = <&tas2563cpu>;

tas2563cpu: simple-audio-card,cpu {
sound-dai = <&sai3>;
system-clock-direction = "out";
};

simple-audio-card,codec {
sound-dai = <&tas2563>;
system-clock-direction = "in";
};
};
};

&sai3 {
fsl,mode = "i2s-master";
assigned-clock-parents = <&clk IMX8MP_AUDIO_PLL1_OUT>;
assigned-clock-rates = <12288000>;
status = "okay";
};

&i2c3 {
tas2563: tasdevice@4c {
status = "okay";
#sound-dai-cells = <0>;
compatible = "ti,tas2563";
reg = <0x4c>;
reset-gpios = <&pca9555 7 GPIO_ACTIVE_LOW>;
};
};

Kind regards,

Christian

Hi Christian,

I doubt this is a problem with the device tree. I think you've showed that the endian is the issue and this has nothing to do with the device itself.

I've looped in our software team to see if they can comment on the driver and if it can be tweaked.

Best regards,
Jeff McPherson

Hi Christian,

pls record wav file with format  S16_BE(Big Endian), not  S16_LE(Little Endian).

Thanks

Kevin

Hello Kevin,

thank you for your reply!

Would you please give me a hint how I can do that? If I enter

# arecord -t raw -c4 -fS16_BE -r48000 -v test.raw --device="hw:0,0"

or

# arecord -c4 -fS16_BE -r48000 -v test.wav --device="hw:0,0"

I get the message:

Recording WAVE 'test.raw' : Signed 16 bit Big Endian, Rate 48000 Hz, Channels 4
arecord: set_params:1352: Sample format non available
Available formats:
- S16_LE
- S24_LE
- S32_LE

Kind regards,

Christian

Could you add macro definition in tasdevice.h ?

Original:

#define TASDEVICE_FORMATS	(SNDRV_PCM_FMTBIT_S16_LE | \
	SNDRV_PCM_FMTBIT_S20_3LE | \
	SNDRV_PCM_FMTBIT_S24_3LE | \
	SNDRV_PCM_FMTBIT_S24_LE | \
	SNDRV_PCM_FMTBIT_S32_LE)

Change to be:

#define TASDEVICE_FORMATS	(SNDRV_PCM_FMTBIT_S16_LE | \
	SNDRV_PCM_FMTBIT_S20_3LE | \
	SNDRV_PCM_FMTBIT_S24_3LE | \
	SNDRV_PCM_FMTBIT_S24_LE | \
	SNDRV_PCM_FMTBIT_S32_LE | \
	SNDRV_PCM_FMTBIT_S16_BE | \
	SNDRV_PCM_FMTBIT_S24_BE | \
	SNDRV_PCM_FMTBIT_S32_BE)

Thanks

Kevin

Hello Kevin,

I changed the definitions in tasdevice.h (at Line 61) as you suggested.

The command

# arecord -t raw -f S16_BE -r 48000 -c 4 test.raw

works. If I import it to audacity as raw data S16_LE 16bits 48 Khz, I get the microphone signals, surprisingly with the microphone signals on channel 1 and 3 instead 1 and 2 as expected.

The command

# arecord -f S16_BE -r 48000 -c 4 test.raw

rejects with the message
Recording WAVE 'test.raw' : Signed 16 bit Big Endian, Rate 48000 Hz, Channels 4
arecord: begin_wave:2679: Wave doesn't support S16_BE format...

Please correct me if I'm wrong, but isn't the origin of the issue that ALSA expects the data to be in S16_LE but receives it in S16_BE?

It's a bit strange that I have to record with S16_BE settings to receive S16_LE data...

Do you see a possibility to change either the driver or the ALSA configuration to match the endianess?

King regards,

Christian

Hi Christian

S16_LE which should be correct, in our device, always MSB first, 

 "surprisingly with the microphone signals on channel 1 and 3 instead 1 and 2 as expected"

The problem should be on TX slot length setting, which is 32bit not 16bit

Pls share your registers dump

Thanks

Kevin

Hello Kevin,

thank you for your answer!

currently, I'm using the settings (ID 5) from tas2563-1amp-reg.json within the tas2781-linux-driver.

please find the following files:

recgcfg_list (cat regcfg_list):

Conf 05: 05-pdm-rec-i2s-48kHz-32bit-tx-slot-0-1-mic-slot-3-ref

block type:PRE_SHUTDOWN device idx = 0x00
SINGLE BYTE:
BOOK0x00 PAGE0x00 REG0x02 VALUE = 0x0e
block type:PRE_POWER_UP device idx = 0x01
FIELD:
BOOK0x00 PAGE0x01 REG0x02 MASK0x1e VALUE = 0x00
SINGLE BYTE:
BOOK0x00 PAGE0x00 REG0x06 VALUE = 0x09
BOOK0x00 PAGE0x00 REG0x08 VALUE = 0x7e
BOOK0x00 PAGE0x00 REG0x0c VALUE = 0x40
BOOK0x00 PAGE0x00 REG0x0b VALUE = 0x42
BOOK0x00 PAGE0x00 REG0x0d VALUE = 0x44
BOOK0x00 PAGE0x00 REG0x30 VALUE = 0x99
BOOK0x00 PAGE0x00 REG0x0a VALUE = 0x13
BOOK0x00 PAGE0x00 REG0x41 VALUE = 0x06
BOOK0x00 PAGE0x00 REG0x07 VALUE = 0x02
BOOK0x00 PAGE0x00 REG0x42 VALUE = 0x18
BOOK0x00 PAGE0x00 REG0x02 VALUE = 0x00

PAGE00-regdump:

addr: 0x4c

Chn0B0x00P0x00R0x00:0x00
Chn0B0x00P0x00R0x01:0x00
Chn0B0x00P0x00R0x02:0x0e
Chn0B0x00P0x00R0x03:0x13
Chn0B0x00P0x00R0x04:0xc6
Chn0B0x00P0x00R0x05:0x22
Chn0B0x00P0x00R0x06:0x09
Chn0B0x00P0x00R0x07:0x02
Chn0B0x00P0x00R0x08:0x7e
Chn0B0x00P0x00R0x09:0x10
Chn0B0x00P0x00R0x0a:0x13
Chn0B0x00P0x00R0x0b:0x42
Chn0B0x00P0x00R0x0c:0x40
Chn0B0x00P0x00R0x0d:0x44
Chn0B0x00P0x00R0x0e:0x05
Chn0B0x00P0x00R0x0f:0x06
Chn0B0x00P0x00R0x10:0x07
Chn0B0x00P0x00R0x11:0x27
Chn0B0x00P0x00R0x12:0x13
Chn0B0x00P0x00R0x13:0x76
Chn0B0x00P0x00R0x14:0x01
Chn0B0x00P0x00R0x15:0x2e
Chn0B0x00P0x00R0x16:0x60
Chn0B0x00P0x00R0x17:0x0e
Chn0B0x00P0x00R0x18:0x0c
Chn0B0x00P0x00R0x19:0x00
Chn0B0x00P0x00R0x1a:0xfc
Chn0B0x00P0x00R0x1b:0xa6
Chn0B0x00P0x00R0x1c:0xdf
Chn0B0x00P0x00R0x1d:0xef
Chn0B0x00P0x00R0x1e:0xff
Chn0B0x00P0x00R0x1f:0x04
Chn0B0x00P0x00R0x20:0x00
Chn0B0x00P0x00R0x21:0x00
Chn0B0x00P0x00R0x22:0x80
Chn0B0x00P0x00R0x23:0x00
Chn0B0x00P0x00R0x24:0x04
Chn0B0x00P0x00R0x25:0x00
Chn0B0x00P0x00R0x26:0x11
Chn0B0x00P0x00R0x27:0x80
Chn0B0x00P0x00R0x28:0x00
Chn0B0x00P0x00R0x29:0xdc
Chn0B0x00P0x00R0x2a:0x51
Chn0B0x00P0x00R0x2b:0xd0
Chn0B0x00P0x00R0x2c:0x7e
Chn0B0x00P0x00R0x2d:0xda
Chn0B0x00P0x00R0x2e:0x00
Chn0B0x00P0x00R0x2f:0xa6
Chn0B0x00P0x00R0x30:0x99
Chn0B0x00P0x00R0x31:0x40
Chn0B0x00P0x00R0x32:0x81
Chn0B0x00P0x00R0x33:0x34
Chn0B0x00P0x00R0x34:0x4b
Chn0B0x00P0x00R0x35:0xa4
Chn0B0x00P0x00R0x36:0x00
Chn0B0x00P0x00R0x37:0x00
Chn0B0x00P0x00R0x38:0x12
Chn0B0x00P0x00R0x39:0x0c
Chn0B0x00P0x00R0x3a:0xbe
Chn0B0x00P0x00R0x3b:0x58
Chn0B0x00P0x00R0x3c:0x58
Chn0B0x00P0x00R0x3d:0x08
Chn0B0x00P0x00R0x3e:0x10
Chn0B0x00P0x00R0x3f:0x00
Chn0B0x00P0x00R0x40:0x76
Chn0B0x00P0x00R0x41:0x06
Chn0B0x00P0x00R0x42:0x18
Chn0B0x00P0x00R0x43:0xc0
Chn0B0x00P0x00R0x44:0x10
Chn0B0x00P0x00R0x45:0x21
Chn0B0x00P0x00R0x46:0x00
Chn0B0x00P0x00R0x47:0x51
Chn0B0x00P0x00R0x48:0x2c
Chn0B0x00P0x00R0x49:0x51
Chn0B0x00P0x00R0x4a:0x60
Chn0B0x00P0x00R0x4b:0x00
Chn0B0x00P0x00R0x4c:0x00
Chn0B0x00P0x00R0x4d:0x00
Chn0B0x00P0x00R0x4e:0x00
Chn0B0x00P0x00R0x4f:0x00
Chn0B0x00P0x00R0x50:0x00
Chn0B0x00P0x00R0x51:0x00
Chn0B0x00P0x00R0x52:0x00
Chn0B0x00P0x00R0x53:0x00
Chn0B0x00P0x00R0x54:0x00
Chn0B0x00P0x00R0x55:0x00
Chn0B0x00P0x00R0x56:0x00
Chn0B0x00P0x00R0x57:0x00
Chn0B0x00P0x00R0x58:0x00
Chn0B0x00P0x00R0x59:0x00
Chn0B0x00P0x00R0x5a:0x00
Chn0B0x00P0x00R0x5b:0x00
Chn0B0x00P0x00R0x5c:0x00
Chn0B0x00P0x00R0x5d:0x00
Chn0B0x00P0x00R0x5e:0x00
Chn0B0x00P0x00R0x5f:0x00
Chn0B0x00P0x00R0x60:0x00
Chn0B0x00P0x00R0x61:0x00
Chn0B0x00P0x00R0x62:0x00
Chn0B0x00P0x00R0x63:0x00
Chn0B0x00P0x00R0x64:0x00
Chn0B0x00P0x00R0x65:0x00
Chn0B0x00P0x00R0x66:0x00
Chn0B0x00P0x00R0x67:0x00
Chn0B0x00P0x00R0x68:0x00
Chn0B0x00P0x00R0x69:0x00
Chn0B0x00P0x00R0x6a:0x00
Chn0B0x00P0x00R0x6b:0x00
Chn0B0x00P0x00R0x6c:0x00
Chn0B0x00P0x00R0x6d:0x00
Chn0B0x00P0x00R0x6e:0x00
Chn0B0x00P0x00R0x6f:0x00
Chn0B0x00P0x00R0x70:0x00
Chn0B0x00P0x00R0x71:0x00
Chn0B0x00P0x00R0x72:0x00
Chn0B0x00P0x00R0x73:0xf0
Chn0B0x00P0x00R0x74:0x00
Chn0B0x00P0x00R0x75:0x0f
Chn0B0x00P0x00R0x76:0x00
Chn0B0x00P0x00R0x77:0x00
Chn0B0x00P0x00R0x78:0x80
Chn0B0x00P0x00R0x79:0x00
Chn0B0x00P0x00R0x7a:0x00
Chn0B0x00P0x00R0x7b:0x00
Chn0B0x00P0x00R0x7c:0x00
Chn0B0x00P0x00R0x7d:0x10
Chn0B0x00P0x00R0x7e:0xb4
Chn0B0x00P0x00R0x7f:0x00
== == == caught smartpa reg end == == ==

PAGE01-regdump

addr: 0x4c

Chn0B0x00P0x01R0x00:0x00
Chn0B0x00P0x01R0x01:0x00
Chn0B0x00P0x01R0x02:0x20
Chn0B0x00P0x01R0x03:0x44
Chn0B0x00P0x01R0x04:0x80
Chn0B0x00P0x01R0x05:0x42
Chn0B0x00P0x01R0x06:0x01
Chn0B0x00P0x01R0x07:0x24
Chn0B0x00P0x01R0x08:0x40
Chn0B0x00P0x01R0x09:0x00
Chn0B0x00P0x01R0x0a:0x52
Chn0B0x00P0x01R0x0b:0x10
Chn0B0x00P0x01R0x0c:0x48
Chn0B0x00P0x01R0x0d:0x02
Chn0B0x00P0x01R0x0e:0x68
Chn0B0x00P0x01R0x0f:0x00
Chn0B0x00P0x01R0x10:0x40
Chn0B0x00P0x01R0x11:0x12
Chn0B0x00P0x01R0x12:0x00
Chn0B0x00P0x01R0x13:0x00
Chn0B0x00P0x01R0x14:0x00
Chn0B0x00P0x01R0x15:0x00
Chn0B0x00P0x01R0x16:0x40
Chn0B0x00P0x01R0x17:0x00
Chn0B0x00P0x01R0x18:0x00
Chn0B0x00P0x01R0x19:0x02
Chn0B0x00P0x01R0x1a:0x00
Chn0B0x00P0x01R0x1b:0x01
Chn0B0x00P0x01R0x1c:0x08
Chn0B0x00P0x01R0x1d:0x00
Chn0B0x00P0x01R0x1e:0x00
Chn0B0x00P0x01R0x1f:0x60
Chn0B0x00P0x01R0x20:0x03
Chn0B0x00P0x01R0x21:0x00
Chn0B0x00P0x01R0x22:0x01
Chn0B0x00P0x01R0x23:0x00
Chn0B0x00P0x01R0x24:0x00
Chn0B0x00P0x01R0x25:0x00
Chn0B0x00P0x01R0x26:0x00
Chn0B0x00P0x01R0x27:0x00
Chn0B0x00P0x01R0x28:0x10
Chn0B0x00P0x01R0x29:0x10
Chn0B0x00P0x01R0x2a:0x02
Chn0B0x00P0x01R0x2b:0x00
Chn0B0x00P0x01R0x2c:0x20
Chn0B0x00P0x01R0x2d:0x01
Chn0B0x00P0x01R0x2e:0x09
Chn0B0x00P0x01R0x2f:0x01
Chn0B0x00P0x01R0x30:0x30
Chn0B0x00P0x01R0x31:0x00
Chn0B0x00P0x01R0x32:0x80
Chn0B0x00P0x01R0x33:0x00
Chn0B0x00P0x01R0x34:0x00
Chn0B0x00P0x01R0x35:0x00
Chn0B0x00P0x01R0x36:0x00
Chn0B0x00P0x01R0x37:0x00
Chn0B0x00P0x01R0x38:0x00
Chn0B0x00P0x01R0x39:0x00
Chn0B0x00P0x01R0x3a:0x00
Chn0B0x00P0x01R0x3b:0x12
Chn0B0x00P0x01R0x3c:0x48
Chn0B0x00P0x01R0x3d:0x10
Chn0B0x00P0x01R0x3e:0x10
Chn0B0x00P0x01R0x3f:0x01
Chn0B0x00P0x01R0x40:0x00
Chn0B0x00P0x01R0x41:0x00
Chn0B0x00P0x01R0x42:0x00
Chn0B0x00P0x01R0x43:0x00
Chn0B0x00P0x01R0x44:0x00
Chn0B0x00P0x01R0x45:0x00
Chn0B0x00P0x01R0x46:0x00
Chn0B0x00P0x01R0x47:0x00
Chn0B0x00P0x01R0x48:0x00
Chn0B0x00P0x01R0x49:0x00
Chn0B0x00P0x01R0x4a:0x00
Chn0B0x00P0x01R0x4b:0x00
Chn0B0x00P0x01R0x4c:0x00
Chn0B0x00P0x01R0x4d:0x00
Chn0B0x00P0x01R0x4e:0x00
Chn0B0x00P0x01R0x4f:0x00
Chn0B0x00P0x01R0x50:0x00
Chn0B0x00P0x01R0x51:0x00
Chn0B0x00P0x01R0x52:0x00
Chn0B0x00P0x01R0x53:0x00
Chn0B0x00P0x01R0x54:0x00
Chn0B0x00P0x01R0x55:0x00
Chn0B0x00P0x01R0x56:0x00
Chn0B0x00P0x01R0x57:0x00
Chn0B0x00P0x01R0x58:0x00
Chn0B0x00P0x01R0x59:0x00
Chn0B0x00P0x01R0x5a:0x00
Chn0B0x00P0x01R0x5b:0x00
Chn0B0x00P0x01R0x5c:0x00
Chn0B0x00P0x01R0x5d:0x00
Chn0B0x00P0x01R0x5e:0x00
Chn0B0x00P0x01R0x5f:0x00
Chn0B0x00P0x01R0x60:0x00
Chn0B0x00P0x01R0x61:0x00
Chn0B0x00P0x01R0x62:0x00
Chn0B0x00P0x01R0x63:0x00
Chn0B0x00P0x01R0x64:0x00
Chn0B0x00P0x01R0x65:0x00
Chn0B0x00P0x01R0x66:0x00
Chn0B0x00P0x01R0x67:0x00
Chn0B0x00P0x01R0x68:0x00
Chn0B0x00P0x01R0x69:0x00
Chn0B0x00P0x01R0x6a:0x00
Chn0B0x00P0x01R0x6b:0x00
Chn0B0x00P0x01R0x6c:0x00
Chn0B0x00P0x01R0x6d:0x00
Chn0B0x00P0x01R0x6e:0x00
Chn0B0x00P0x01R0x6f:0x00
Chn0B0x00P0x01R0x70:0x00
Chn0B0x00P0x01R0x71:0x00
Chn0B0x00P0x01R0x72:0x00
Chn0B0x00P0x01R0x73:0x00
Chn0B0x00P0x01R0x74:0x00
Chn0B0x00P0x01R0x75:0x00
Chn0B0x00P0x01R0x76:0x00
Chn0B0x00P0x01R0x77:0x00
Chn0B0x00P0x01R0x78:0x00
Chn0B0x00P0x01R0x79:0x00
Chn0B0x00P0x01R0x7a:0x00
Chn0B0x00P0x01R0x7b:0x00
Chn0B0x00P0x01R0x7c:0x00
Chn0B0x00P0x01R0x7d:0x00
Chn0B0x00P0x01R0x7e:0x00
Chn0B0x00P0x01R0x7f:0x00
== == == caught smartpa reg end == == ==

Kind regards,

Christian

Hello Kevin,

as you didn't answer to my post from last week - do you see a chance to get the PDM microphone data to ALSA using your Linux driver?

By the way: the issue concerning channel 1 and 3 in the previous post resulted from some alsa setting: I was playing around with the settings. Using S16_BE in the config file results having the data on channel 1 and 3 and S16_SE puts the data on channel 1 and 2 as expected.

BUT: both and all other setting record the data in wrong byte order: recording with format S16_LE (arecord) results in data with S16_BE and vice versa - regardless of the settings in asound.conf - the only difference is the channel within the raw file.

So, recording a simple .wav file currently is not possible.

The setting for receiving data on channel 1 and 2, bit with wrong byte order, is following:

pcm.test{
type dsnoop
ipc_key 123456
slave {
pcm "hw:0,0"
channels 4
format S16_LE
rate 48000
}
}

Recording data with >arecord -t raw -f S16_LE -r 48000 -c 4 filename.raw< and importing it to audacity with following settings results in usable audio data, but as you can see, the byte order does not match the settings in arecord. Therefore, audio record in Linux is not possible without very dirty hacking of the audio stream. Standard .wav files are corrupted.

Looking forward to your professional support.

Kind regards,

Christian

Hi Christian,

Sorry for delayed response since I was on vacation last week, I will transfer thread to Shenghao to answer.

Thanks

Kevin

Hi, Guy

Kindly try setting B0P0R0xA:TX_OFFSET to 0, 2, 3, 4, 5, 6, 7

Hi, thanks for your answer.

Just to make sure that I have understood you correctly:

I should try the different settings 0x0, 0x2, 0x3, 0x4, 0x5, 0x6, 0x7 in register B0P0R0xA:TX_OFFSET and see the differences?

Yes

Hello!

I tried the different settings - TX_EDGE and TX_FILL (0x13, which was the previous setting) does not seem to make any difference. TX_OFFSET[2:0] seems to move the data backwards but does not change the byte order - with the effect to lower the signal if imported with BIG ENDIAN.

The following pictures were recorded with

arecord -t raw -f S16_LE -r 48000 -c 4 -d 2 filename.raw

The first 4 channels show the raw file imported with LITTLE ENDIAN and channel 5 to 8 with BIG ENDIAN. The other importing settings the same as shown in the screenshot in one of the previous posts.

0x0:

0x2:

0x3:

0x4:

0x5:

0x6:

0x7:

0x13:

Kind regards,

Christian

Hi Guy,

Thanks for your verification. kindly stop that trying.

Can you upload the wav file with the default setting of TX_OFFSET?

According to Chn0B0x00P0x00R0x11:0x27, it seemed that the samplerate is not detected, and bitwidth is 64-bit.

Kindly measure both bck and ws clk with scope, ans share the waveform here.

Also, kindly check the PMIC whether it have some setting for byte endian. 

One more thing, the register dump you shared is not in working mode. kindly use following commands:

arecord -t raw -f S16_LE -r 48000 -c 4 -d 2 filename.raw &   // & is to force the command to the background

Then dump the book0page0 registers 

Hello,

Thank you for your answer!

Please find the requested files at https://www.demmel.com/nc/index.php/s/AGM5z3DzMSF9dZx

The .zip archive contains the regdump (20240708_regdump_PAGE00.txt) while recording with including the corresponding .raw file

arecord -t raw -f S16_LE -r 48000 -c 4 test_a13_regdump.raw -d 5

a second file recordes as .wav recorded with

arecord -f S16_LE -r 48000 -c 4 test_a13_regdump.wav -d 5

and the regbin settings (regbin_a13.txt).

We use two of the Infineon IM72D128V01 mics, but I didn't find any possibility to adjust the byte order - please find the datasheet here:

https://www.infineon.com/dgdl/Infineon-IM72D128-DataSheet-v01_01-EN.pdf?fileId=8ac78c8c80027ecd0180612a60277e10

The scope measurements will come with an additional post. Just to ensure: I2S bit clock: SBCLK1 (QFN pin 6) and I2S frame sync: FSYNC (QFN pin 5) on the TAS2563, correct?

We are using the QFN package.

Kind regards,

Christian

Hello again,

please find the scope images in various time resolutions.

CH1 is SBCLK1, CH2 is FSYNC

The measurements were taken during audio recording.

Kind regards,

Christian

Hi, Guy,

1. try setting BOOK0x00 PAGE0x00 REG0x02 VALUE = 0x70 before running arecord, if now work, then revert this setting, try next
2. Can you try following command,  arecord -t raw -f S32_LE -r 48000 -c 2 test.raw & // attention: & can push arecord working in the background
3. One more thing, kindly confirm whether PDM support Little Endian setting
4. As to the register dump, the register dump you offered is not in working mode, b0p0r2=0xe. which clues tas2563 is power off. do not append & in your arecord command.

Hello,

ad 1: I don't exactly understand your advise - what I did was:

- write 0x70 to register 0x02 and record: no effect was shown

- changing the regbin file - last entry of PRE_POWER_UP to BOOK0x00 PAGE0x00 REG0x02 VALUE = 0x70: the effect was a little distortion (a little bit like jitter) on playback and the same on record, but nothing on endianess. I reverted this setting as you wrote. My current regbin settings are (as before):

Conf 06: 06-pdm-rec

block type:PRE_SHUTDOWN     device idx = 0x00
        SINGLE BYTE:
            BOOK0x00 PAGE0x00 REG0x02 VALUE = 0x0e
            BOOK0x00 PAGE0x00 REG0x41 VALUE = 0x46
block type:PRE_POWER_UP     device idx = 0x01
        FIELD:
            BOOK0x00 PAGE0x01 REG0x02 MASK0x1e VALUE = 0x00
        SINGLE BYTE:
            BOOK0x00 PAGE0x00 REG0x06 VALUE = 0x09
            BOOK0x00 PAGE0x00 REG0x08 VALUE = 0x7e
            BOOK0x00 PAGE0x00 REG0x0b VALUE = 0x40
            BOOK0x00 PAGE0x00 REG0x0c VALUE = 0x42
            BOOK0x00 PAGE0x00 REG0x0d VALUE = 0x44
            BOOK0x00 PAGE0x00 REG0x0a VALUE = 0x13
            BOOK0x00 PAGE0x00 REG0x30 VALUE = 0x99
            BOOK0x00 PAGE0x00 REG0x41 VALUE = 0x06
            BOOK0x00 PAGE0x00 REG0x42 VALUE = 0x18
            BOOK0x00 PAGE0x00 REG0x07 VALUE = 0x02
            BOOK0x00 PAGE0x00 REG0x02 VALUE = 0x00

ad 2: You can find the file here: https://www.demmel.com/nc/index.php/s/DnxxeBonfcsGiSZ

(still wrong byte order)

ad 3: I cannot find any hint regarding any byte order in the datasheet of the PDM microphone - https://www.infineon.com/dgdl/Infineon-IM72D128-DataSheet-v01_01-EN.pdf?fileId=8ac78c8c80027ecd0180612a60277e10

but: they worked using PPC3, your evaluation kit TAS2x63EVM and your Windows drivers. 

ad 4: I added the regdump to the .zip file in the previous post stating  Chn0B0x00P0x00R0x02:0x00

once again as text:

addr: 0x4c

Chn0B0x00P0x00R0x00:0x00
Chn0B0x00P0x00R0x01:0x00
Chn0B0x00P0x00R0x02:0x00
Chn0B0x00P0x00R0x03:0x10
Chn0B0x00P0x00R0x04:0xc6
Chn0B0x00P0x00R0x05:0x22
Chn0B0x00P0x00R0x06:0x09
Chn0B0x00P0x00R0x07:0x02
Chn0B0x00P0x00R0x08:0x7e
Chn0B0x00P0x00R0x09:0x10
Chn0B0x00P0x00R0x0a:0x13
Chn0B0x00P0x00R0x0b:0x40
Chn0B0x00P0x00R0x0c:0x42
Chn0B0x00P0x00R0x0d:0x44
Chn0B0x00P0x00R0x0e:0x05
Chn0B0x00P0x00R0x0f:0x06
Chn0B0x00P0x00R0x10:0x07
Chn0B0x00P0x00R0x11:0x24
Chn0B0x00P0x00R0x12:0x13
Chn0B0x00P0x00R0x13:0x76
Chn0B0x00P0x00R0x14:0x01
Chn0B0x00P0x00R0x15:0x2e
Chn0B0x00P0x00R0x16:0x60
Chn0B0x00P0x00R0x17:0x0e
Chn0B0x00P0x00R0x18:0x0c
Chn0B0x00P0x00R0x19:0x00
Chn0B0x00P0x00R0x1a:0xfc
Chn0B0x00P0x00R0x1b:0xa6
Chn0B0x00P0x00R0x1c:0xdf
Chn0B0x00P0x00R0x1d:0xef
Chn0B0x00P0x00R0x1e:0xff
Chn0B0x00P0x00R0x1f:0x00
Chn0B0x00P0x00R0x20:0x00
Chn0B0x00P0x00R0x21:0x11
Chn0B0x00P0x00R0x22:0x00
Chn0B0x00P0x00R0x23:0x00
Chn0B0x00P0x00R0x24:0x00
Chn0B0x00P0x00R0x25:0x00
Chn0B0x00P0x00R0x26:0x11
Chn0B0x00P0x00R0x27:0x80
Chn0B0x00P0x00R0x28:0x00
Chn0B0x00P0x00R0x29:0x4c
Chn0B0x00P0x00R0x2a:0x51
Chn0B0x00P0x00R0x2b:0xd0
Chn0B0x00P0x00R0x2c:0x79
Chn0B0x00P0x00R0x2d:0xda
Chn0B0x00P0x00R0x2e:0x00
Chn0B0x00P0x00R0x2f:0xa3
Chn0B0x00P0x00R0x30:0x99
Chn0B0x00P0x00R0x31:0x40
Chn0B0x00P0x00R0x32:0x81
Chn0B0x00P0x00R0x33:0x34
Chn0B0x00P0x00R0x34:0x4b
Chn0B0x00P0x00R0x35:0xa4
Chn0B0x00P0x00R0x36:0x00
Chn0B0x00P0x00R0x37:0x00
Chn0B0x00P0x00R0x38:0x12
Chn0B0x00P0x00R0x39:0x0c
Chn0B0x00P0x00R0x3a:0xbe
Chn0B0x00P0x00R0x3b:0x58
Chn0B0x00P0x00R0x3c:0x54
Chn0B0x00P0x00R0x3d:0x08
Chn0B0x00P0x00R0x3e:0x10
Chn0B0x00P0x00R0x3f:0x00
Chn0B0x00P0x00R0x40:0x76
Chn0B0x00P0x00R0x41:0x06
Chn0B0x00P0x00R0x42:0x18
Chn0B0x00P0x00R0x43:0xc0
Chn0B0x00P0x00R0x44:0x10
Chn0B0x00P0x00R0x45:0x21
Chn0B0x00P0x00R0x46:0x00
Chn0B0x00P0x00R0x47:0x51
Chn0B0x00P0x00R0x48:0x2c
Chn0B0x00P0x00R0x49:0x51
Chn0B0x00P0x00R0x4a:0x40
Chn0B0x00P0x00R0x4b:0x03
Chn0B0x00P0x00R0x4c:0x00
Chn0B0x00P0x00R0x4d:0x00
Chn0B0x00P0x00R0x4e:0x00
Chn0B0x00P0x00R0x4f:0x00
Chn0B0x00P0x00R0x50:0x00
Chn0B0x00P0x00R0x51:0x00
Chn0B0x00P0x00R0x52:0x00
Chn0B0x00P0x00R0x53:0x00
Chn0B0x00P0x00R0x54:0x00
Chn0B0x00P0x00R0x55:0x00
Chn0B0x00P0x00R0x56:0x00
Chn0B0x00P0x00R0x57:0x00
Chn0B0x00P0x00R0x58:0x00
Chn0B0x00P0x00R0x59:0x00
Chn0B0x00P0x00R0x5a:0x00
Chn0B0x00P0x00R0x5b:0x00
Chn0B0x00P0x00R0x5c:0x00
Chn0B0x00P0x00R0x5d:0x00
Chn0B0x00P0x00R0x5e:0x00
Chn0B0x00P0x00R0x5f:0x00
Chn0B0x00P0x00R0x60:0x00
Chn0B0x00P0x00R0x61:0x00
Chn0B0x00P0x00R0x62:0x00
Chn0B0x00P0x00R0x63:0x00
Chn0B0x00P0x00R0x64:0x00
Chn0B0x00P0x00R0x65:0x00
Chn0B0x00P0x00R0x66:0x00
Chn0B0x00P0x00R0x67:0x00
Chn0B0x00P0x00R0x68:0x00
Chn0B0x00P0x00R0x69:0x00
Chn0B0x00P0x00R0x6a:0x00
Chn0B0x00P0x00R0x6b:0x00
Chn0B0x00P0x00R0x6c:0x00
Chn0B0x00P0x00R0x6d:0x00
Chn0B0x00P0x00R0x6e:0x00
Chn0B0x00P0x00R0x6f:0x00
Chn0B0x00P0x00R0x70:0x00
Chn0B0x00P0x00R0x71:0x00
Chn0B0x00P0x00R0x72:0x00
Chn0B0x00P0x00R0x73:0xf0
Chn0B0x00P0x00R0x74:0x00
Chn0B0x00P0x00R0x75:0x0f
Chn0B0x00P0x00R0x76:0x00
Chn0B0x00P0x00R0x77:0x00
Chn0B0x00P0x00R0x78:0xcc
Chn0B0x00P0x00R0x79:0x00
Chn0B0x00P0x00R0x7a:0x00
Chn0B0x00P0x00R0x7b:0x00
Chn0B0x00P0x00R0x7c:0x00
Chn0B0x00P0x00R0x7d:0x10
Chn0B0x00P0x00R0x7e:0x64
Chn0B0x00P0x00R0x7f:0x00
 == == == caught smartpa reg end == ==  ==

Kind regards and thank you for your support,

Christian

Hi Christian,

Can you please share a scope capture of the SDOUT data along with FSYNC? This can be just for a few samples. I'd like to verify the data "shape" looks OK.
In general, for TX or RX of data, MSB is always the left-most bit. There's some format configuration options, but that's limited to the ones below, there's no way to change MSB location:

• Offset: this is how many empty bits are included in each slot, if any.
• Justification: this is how the data bits are positioned in the slot, moving the offset bits (if any) to the opposite side.
• I2S/TDM: this is how a frame starts with respect to FSYNC edge.

If the data is coming out of the device as expected, then the problem must be on the way the data is then translated into wav format.

Best regards,
-Ivan Salazar
Applications Engineer

Hello Ivan,

thank you for your reply!

Please find the requested captures (CH1: SBCLK1, CH2: FSYNC, CH3: DATA_SDOUT1):

If this captures are as expected:

Which element converts the data from I2S to .wav? Isn't the driver responsible for that conversion? At least, I don't know, where to have an influence to that conversion. (I already tried out some settings with S16_BE in alsa.conf, but without success). Is there any option to change the driver configuration e.g. in the device tree?

We are using the driver from https://git.ti.com/cgit/tas2781-linux-drivers/tas2781-linux-driver/tree/ in combination with the simple-audio-card and the sai3 interface coming from the NXP BSP (kernel version 5.15.71). I've already posted our device tree and alsa.conf settings in previous messages.

Kind regards,

Christian

Hi Christian,

Are these captures with PDM data running from the microphone? It seems almost all the bits are Hi?
Can you try capturing SDOUT data again while holding PDMD both Hi and Lo?

Best regards,
-Ivan Salazar
Applications Engineer

Hello Ivan!

Yes, the data was with the PDM-Microphones (2 pieces).

I'm not absolutely sure how the I2S data should look like, but it seems to be inverted:

The first three pictures are with PDMD at GND level:

And the next images show PDMD at 3V3:

Kind regards,

Christian

Hi Christian,

Thanks, I'll double check the same waveforms on my side tomorrow and get further comments.

Best regards,
-Ivan Salazar
Applications Engineer

Hello Ivan,

thank you - I look forward to your results and suggestions!

Kind regards,

Christian

Christian,

I couldn't make time for this today, I'll get back to you tomorrow.
Sorry for the delay.

Best regards,
-Ivan Salazar
Applications Engineer

Hi Christian,

I verified similar setup on my side, the resulting SDOUT for PDM forced Hi and Lo seems correct. At this point hardware side looks OK.

I don't know what is handling the data translation/storage after receiving the signals from TAS2563.
Sorr if you mentioned this already, but have you tested playback side as well? Is that working OK?

Best regards,
-Ivan Salazar
Applications Engineer

Hi Ivan,

yes, the playback side is working fine (operating with 16 bits / 48 kHz), as I already mentioned.

I've already posted within this thread:

- my device tree settings

- the regbin settings

- alsa.conf settings

- the driver used: https://e2e.ti.com/support/audio-group/audio/f/audio-forum/1328857/tas2563-register-settings-for-48khz-24-bits---mono-out-2x-stereo-in-pdm

- hardware version: TAS2563 QFN

From my point of view, the is a very high probability that the issue originates either from the codec driver or from its connection to the Linux ALSA system.

As we are running out of time slowly, we really require your support on this topic. Do you have a setup using this driver, a Yocto based Linux distribution (not android), and connected PDM microphones to test it on your side?

Kind regards,

Christian

Hi Christian,

I don't have such setup; I'm mainly supporting the amplifier itself and its settings. I'll check back again with SW specialists on how we can help.

Best regards,
-Ivan Salazar
Applications Engineer

Have you consulted with platform vendor on this issue? In our previous PDM projects, the data is little endian.

Hello,

I consulted the nxp support (platform is an i.MX8M-Plus running yocto kirkstone on kernel 5.15.71). They told me that the endianess has to be changed in kernel mode with a link to https://kernelnewbies.org/EndianIssues.

But where is the data captured within your driver to convert it?

Kind regards,

Christian

As you know, our driver is the slave one.

The audio data can be got in the tas2563 driver, the audio data transfer is only via DMA between i2s and CPU.

We have a very old driver, you can try this and check whether the issue will disappear.

tas256xsw-android/tas2563-android-driver - Software for TAS256x on Android Platforms - TAS2563 Android Driver (ti.com)