PDM microphone on nrf54l15

I am unable to read PDM microphone on my custom board or nrf54l15-dk.

My environment:

- nRF Connect SDK v3.0.2

- nrf54l15-dk

- custom board with Fanstel BM15C - nrf54l15 CPU

- T3902 PDM mic - setup as right channel.

Using the sample code I created a simple app that should read the PDM microphone using Zephyr DMIC API on my custom board. But, after a few seconds, I am only getting the same sample value all the time, -320.

- I want to use 400 kHz clock with 50x decimation -> 8000 samples per second, driver calculates correct values, also returns correct number of bytes per second (16000 bytes). I am assuming I am getting int16_t values, soon after start sample values converge to -320 and then stay -320.

- I moved the code to nrf54l15-dk. I have no microphone connected there, so I just output the clock to P1.11 and read pin P1.12 (left unconnected). A few seconds after start, I get the same value as on my custom board (that has the mic connected), -320

- On the DK I raised the P1.12 pin to match the rail voltage, then PDM returns samples +319.

pdm.zip

What am I doing wrong? I tried left and right channel, different clocks, ...

I am attaching a simple app for nrf54l15-dk. On the DK, shouldn't I get sample values close to +32767 when I force the data pin high and probably sample value close to -32768 when I leave the data pin unconnected?

Parents
  • Hello,

    The reason you don't see the full scale output ( -32768 or 32768) when tying the input to gnd or vdd is likely because of the decimation filter. I got the same result here as well. However, I think it may be more relevant to look at the output from the mic to understand why the sample value converges to -320. This suggests that the output goes low and remains low. Are you able to confirm this with an oscilloscope or logic analyzer?

    Best regards,

    Vidar

Reply
  • Hello,

    The reason you don't see the full scale output ( -32768 or 32768) when tying the input to gnd or vdd is likely because of the decimation filter. I got the same result here as well. However, I think it may be more relevant to look at the output from the mic to understand why the sample value converges to -320. This suggests that the output goes low and remains low. Are you able to confirm this with an oscilloscope or logic analyzer?

    Best regards,

    Vidar

Children
  • Hi Vidar,

    Thank you for your response. I already spent a lot of time on this with no result - and the API seems pretty straightforward...

    So:

    - It seems I do not understand then how PDM works - constant low data signal will not produce -32000 and constant high data signal will not produce +32000. Do you know of any online explanation on this subject?

    - I connected logic analyzer to the DK PDM clock pin (running the previously attached sample) to confirm that it is ticking at 400 kHz. It is...

    - On custom board I cannot connect to clock or data pins. But I tried 3 samples of the same board, all behave the same.

    - Can you please confirm that the attached app correctly reads PDM microphone? 

    So, I need to find somebody able to connect an oscilloscope to traces on the custom board. The other thing I can do is get an evaluation board for the mic and connect it to DK to confirm that my app works.  

    BR,
    Marko

  • Hi Vidar,

    1. Well, I accidentaly managed to get my mic to work. The issue was that I used P1.03 pin as clock, and on nrf54l this pin is by default assigned to NFC. So adding this to my DTS file solved the problem:

    &uicr {
      nfct-pins-as-gpios;
    };
    Please confirm that this is the correct way to do this on nrf54l - the dts yaml file talks only about nrf52 and nrf53 chips.
    If so - are there any other pins that need this kind of "let me be normal gpio pin" treatment except for reset pin?
    2. I found the above setting while reading about UICR.
    - Is this setting persistent on nrf54l or does the appropriate startup code need to be executed every time?
    - Is there any high(er) level API for using FICR and UICR or are NRF_UICR and NRF_FICR structs the way to go?
    BR, Marko
  • Hi Marko,

    I'm glad to hear you found the problem, thank you for the update. Yes, adding the nfct-pins-as-gpios; property to the uicr node is the correct approach for now even though the 54l does not have a register for this in UICR like the 52/53 series did.  We are doing the same in our tests as you can see here:

    The NRF_CONFIG_NFCT_PINS_AS_GPIOS flag will be set when you have the nfct-pins-as-gpios property defined in your devictree ensuring that this line is executed on every boot: https://github.com/zephyrproject-rtos/hal_nordic/blob/54f33f10a0b826174fb145f155afa61ce5a44b93/nrfx/mdk/system_nrf54l.c#L226 

    Please refer to the pin assigments chapter of the nRF54l15 datasheet for more details: https://docs.nordicsemi.com/bundle/ps_nrf54L15/page/chapters/pin.html 

    Best regards,

    Vidar

Related