Using PDM causes BLE connection to drop

[brianatcarrot]

We have a custom board using a nRF52840 module and a PDM peripheral. Some of our recently produced boards are experiencing issues with dropped BLE connections when we turn on PDM. The boards continue to work otherwise and the PDM signals the boards are receiving are fine. There are no issues with BLE communication as long as PDM is not running. Our firmware is based on nRF5 SDK 15 and we are using the NRFX PDM driver.

On the affected boards, the behavior seems to be temperature dependent. We can communicate over BLE while PDM is running at higher temperatures of >35°C, but as we lower the temperature, we start having BLE communication issues. Once a board starts experiencing the issue, the radio stops working completely over the span of about 3°C. Different boards encounter the issue at different temperatures, and most of them are fine all the way down to 0°C which is where we stopped testing.

We're using pins 0.24 and 0.25 for PDM, which don't have any high frequency restrictions in the datasheet. Also, we have found that if we remove the PDM peripheral from an affected board, the BLE issue doesn't occur anymore even if we turn on PDM.

I tried searching the forum for similar issues, but the closest I was able to find was this one, where BLE was causing problems with the PDM signal. We have the inverse issue. https://devzone.nordicsemi.com/f/nordic-q-a/53823/pdm-conflict-with-bluetooth-transceiver

[brianatcarrot]

Here's an update for anybody who stumbles across this post in the future. We were unable to figure out the root cause of the problem. However, we did figure out two workarounds.

Workaround one is moving your PDM peripheral to a different pin seems to fix it. That requires hardware changes though, which isn't always possible.

Workaround two can be done entirely in firmware and takes advantage of the fact that the temperature where the BLE communication issues start is apparently dependent on the PDM clock rate. Higher clock rates generally decreased the temperature where we started seeing the issue, but it wasn't universal. That means that if your application can handle using a different PDM clock rate, you might be able to get the temperature cutoff to outside of your operating range. Downsampling or changing the PDM decimation ratio can help if you're going to a higher clock rate. The other way to take advantage of this is for screening your units in manufacturing. If you can find a PDM clock rate that's affected at higher temperatures than the rate you use in the field, you can use that for screening at room temperature and be pretty sure you caught anything that would be affected at cold temperatures.

[jrowberg]

I'm troubleshooting a problem surprisingly similar to this, except with SPI instead of PDM. Out of curiosity, can you tell me what clock source you're using in your custom design? I have a SiTime TCXO providing a 32768Hz clock source for two components on the board (BT + IMU). With the IMU inactive, I can maintain a BLE connection as long as I want, with the clock accuracy set to 20ppm. But as soon as I start communicating with the IMU, suddenly the connection drops--but only on a small percentage of the produced units. Setting the accuracy to 500ppm does not change the behavior.

(IMPORTANT NOTE I FORGOT: Switching the clock source to SYNTH instead of XTAL solves the problem, at the obvious expense of higher current consumption. This is why I think it's related to the clock source.)

After I read your post, I figured "what the heck" and started blasting my current test unit with hot air to see what would happen. INCREDIBLY, after 30 seconds or so of this, the connection suddenly held for a solid minute--a first for this particular device, which always failed after not more than one second. After I let it cool down a while, it's back to its old unstable self.

I'm just wondering if you also have a TCXO, or if you're using some other clock signal. I'm still trying to nail this down.

[brianatcarrot]

The module we're using has a 32 MHz crystal on board, but we don't have any other external crystals. We're using RC as our clock source.

Which pins are you using for SPI? I'm curious if you're using the same ones we were having PDM issues with.

For your test with SYNTH, were you able to switch the clock source on the fly, or was that test using SYNTH full time?

[jrowberg]

Interesting. I'm using the u-blox (ex-Rigado) BMD-340 with the nRF52840 chipset inside. It does have its own HF crystal as well, but no LF crystal.

The SPI pins in my case are P1.13 (MISO), P1.14 (MOSI), and P1.15 (SCK). The CS pin for the slave device in question is P1.12.

My SYNTH test was a full-time change made in sdk_config.h. However, I'm pursuing a possible runtime switch as a workaround for our existing hardware in case I can't figure anything else out.

In case you're interested, I've got my own support topic going over here: devzone.nordicsemi.com/.../spi-transfers-cause-ble-connection-timeout-but-only-on-some-units-and-especially-when-cold