MEMS pdm microphone - custom board

[Jan Slavot�nek]

Posted on August 10, 2017 at 13:33

Hi community!

So far i have been developing my audio application on discovery board STM32F407 (there is a embedded MEMS microphone connected to I2S2), I have been able to configure I2S2 periphery and acquire data with relative ease. 

But now i had to move to custom hardware (i went for STM32F427VG). In discovery board's schematic i have found that the microphone used is MP45DT02. So i have used the very same in my custom board. 

My finished board come so i have tryed to apply the same settings for I2S and expected, that i will have the same results. After compile the program and loadto the target it didnt work properly, so i started troubleshooting by looking at I2S circullar buffer.  The buffer is uint16_t type and after inspecting its content after start it was properly initialized to 0, when i start the program and stop i can see that my HAL_I2S_RxHalfCpltCallback and HAL_I2S_RxCpltCallback are occuring, but all uint16_t elements of the buffer holds 0xFFFF -> that is cleary bad. Normal 'healthy' pdm data looks like random numbers. 

I went even further with my investigation and connected scope to data and clck lines. There another surprise: At discovery board, there is something like 'return to middle' signal shape and my mew mems mic has regular square shape. But anyway i can clearly see in the signal, that there are some 'zero bits' so i dont understand why i get 0xFFFF in all elements of my buffer ...

Also i am wondering, the discovery board's microphone is black (can not read anything out of it) and my MP45DT02TR is silver. So clearly STM did not use the MP45DT component and switched for something different?

See pictures. I will be grateful for any suggestions!

#pdm #mems-microphones #stm32f4

[waclawek.jan]

Posted on August 10, 2017 at 14:29

There another surprise: At discovery board, there is something like 'return to middle' signal shape

The microphone's output is 'active' only during half of the clock cycle, and Hi-Z during the other (depending on LR pins state). If the data line is pulled into mid, it will look like the first waveform. You can do it e.g. by switching both internal pullup and pulldown of the given pin of 'F4 at the same time; or by adding external resistor divider. There is a pulldown resistor on the DISCO in the 'feedback' path from microphone to the CODEC's AIN4A/B.

But anyway i can clearly see in the signal, that there are some 'zero bits' so i dont understand why i get 0xFFFF in all elements of my buffer ...

If you've observed the waveform directly on the 'F4's input pin as you've been supposed to, then you have some bug in software.

Also i am wondering, the discovery board's microphone is black (can not read anything out of it) and my MP45DT02TR is silver.

There used to be both forms, distinguished with -M suffix for 'metal', see

http://www.mouser.com/ds/2/389/mp45dt02-955096.pdf

  .

Did you notice this microphone is marked as NRND?

JW

[Jan Slavot�nek]

Posted on August 10, 2017 at 15:34

Another observation: When i disconected data line from the microphone, i can see on logical zero on the line with my scope (approximately 200mV), but the I2S periphery reads out the 0xFFFF (logical 1s). Why is that? 

[Jan Slavot�nek]

Posted on August 10, 2017 at 15:16

There another surprise: At discovery board, there is something like 'return to middle' signal shape

The microphone's output is 'active' only during half of the clock cycle, and Hi-Z during the other (depending on LR pins state). If the data line is pulled into mid, it will look like the first waveform. You can do it e.g. by switching both internal pullup and pulldown of the given pin of 'F4 at the same time; or by adding external resistor divider. There is a pulldown resistor on the DISCO in the 'feedback' path from microphone to the CODEC's AIN4A/B.

Ok i know about that Hi Z state during the other half of the clk period (so the mics can be used in L-R stereo configuration). But i dont understand, why i dont have the same hi Z state at my

MP45DT02 on my custom board (Or maybe i have and i just miss the pulling part)?I dont see any external pull up or down in schematic of discovery board on PC3 pin and i cant see pull up / down setup at the PC3 GPIO in my cubemx. So i dont know whereis this mysterious 'pull to the middle' component at the discovery board ...

But anyway i can clearly see in the signal, that there are some 'zero bits' so i dont understand why i get 0xFFFF in all elements of my buffer ...

If you've observed the waveform directly on the 'F4's input pin as you've been supposed to, then you have some bug in software.

Yeah i have put ociloscope probe to the data and clock lines of the mic (both on discovery and my custom board). My custom board mems didnt have the 'pull to the middle' property, but clearly i could see the zero bits here and there in the signal, but all of the values read by I2S and transferred by DMA to the buffer are 0xFFFF (all bits high). The I2S periphery is running (because i get halfcplt and cplt callbacks and buffer is being filled by invalid values 0xFFFF). Where is the problem i dont know so far

:(

.

Also i am wondering, the discovery board's microphone is black (can not read anything out of it) and my MP45DT02TR is silver.

There used to be both forms, distinguished with -M suffix for 'metal', see

/external-link.jspa?url=http%3A%2F%2Fwww.mouser.com%2Fds%2F2%2F389%2Fmp45dt02-955pdf

.

Did you notice this microphone is marked as NRND?

JW

So yeah probably they are the very same device, just variations in cover (metal, plastic,...) I have found another discovery board on my desk with the silver version too.

I hope i will find out why my custom board is not able to obtain valid data from Mic, i need to finish my project soon.

Jan

[waclawek.jan · Accepted solution]

Posted on August 10, 2017 at 15:35

Yeah i have put ociloscope probe to the data and clock lines of the mic

You always want to put the probe on the 'consuming' pin, i.e. the data pin on the mcu.

JW

[Jan Slavot�nek]

Posted on August 10, 2017 at 15:44

Well i think it cant harm to scope both lines can it? Why not see both of them. Or maybe you mean that you would put the probe exactly on the pin on on the mcu. I understand your point, but there is no other component between the Microphone pin and mcu pin. So basically it doesnt matter where on the path between microphone and mcu i put my probe. Or am I missing something?

[waclawek.jan]

Posted on August 10, 2017 at 16:19

Don't waste time discussing, do it.

JW

PS.

there is no other component between the Microphone pin and mcu pin

there are at least two solder joints, potentially bad (studenak)

[Jan Slavot�nek]

Posted on August 11, 2017 at 10:51

Problem solved. 

The problem was rather silly - i have realised, that in my design there is a solder bridge to chose if i use PC3 or PC2 pin (one for master I2S, second is for slave case). Naturally after i have connected signal to the correct pin, suddenly my app works like a charm (no matter the square shape of signals obviously).

I am sorry for not contributing an interesting matter to the forum. At least maybe someone can benefit from signal descriptions i have posted. 

Jan 

[Jan Slavot�nek]

Posted on August 11, 2017 at 10:40

Jan i have to thank you. The problem was rather silly - as you mentioned to try get with my probes as close to the mcu i have finally realised, that i have a solder bridge there to chose if i use PC3 or PC2 pin (one for master I2S, second is for slave case). Naturally after i have connected signal to the right pin, suddenly my app works like a charm (no matter the square shape of signals obviously).

Thanks for your help 

cheers

Jan