2025-12-31 8:13 AM
Hello,
Due to limitations with the STM32WBA's silicon & Bluetooth stack we've had to significantly re-engineer our hardware and add an external Bluetooth chip. As part of this, we updated our SAI blocks so that one block is transmit and one is receive, and moved our PDM microphones to a SPI bus.
Since we have two PDM microphones, we've followed AN5027 "Interfacing PDM Digital Microphones":
In our setup, we have SPI2 SCK (mapped to PB10) connected to PA1, and connected PA9 to the DMIC_CLK line. Our plan has been to map PA1 (input) -> TIM17_CH1, which then triggers (via ITR8) TIM3_CH2 which is mapped to PA9 (output).
However, I'm struggling to set up the signals properly. I am able to configure TIM17_CH1 so that I can count SPI2_SCK. However, I am unable to trigger TIM3 to count at all.
I've attached my example project for the NUCLEO-WBA65RI board.
Any insight on this issue?
Thank you,
Jonathan
2026-01-02 1:39 AM
Just - which PDM microphone you use?
2026-01-05 6:31 AM
Hello,
The STM32WBA is a multiprotocol solution that includes Bluetooth® Low Energy (LE) Audio as specified by the Bluetooth Special Interest Group (SIG).
The STM32WBA Bluetooth® LE development is fully certified and does not contain any limitations for developing Bluetooth® Low Energy solutions.
This product is not intended to support (old) third-party proprietary audio development based on classic (ACL) Bluetooth® Low Energy technology.
The following links provide information on features fully supported by STM32WBA for Bluetooth® Low Energy audio development and Auracast™ support, which represents the future of this technology and brings innovation.
Regards
Lionel
2026-01-06 5:26 AM
@AScha.3 For this example, I am using this shield: https://www.st.com/en/evaluation-tools/x-nucleo-cca02m2.html.
@Lionel Chastillon : I'm not sure I understand your response -- was this meant for me?
What has been working for me is setting up the SPI interface as a SPI half-duplex slave, and generating the clock with TIM17, and triggering TIM3 via capture/compare from TIM17. Is there any reason to be concerned about this approach?