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

[Susheel Nuguru]

I am a bit unsure what might be wrong on the SDK which is that old (nRF5SDKv15)

There are two things that I can think of

1. Try to reproduce this on the nRF52840 DK and see if you have same issues.
   1. If you have same issues, then it most likely is related to the software configuration.
   2. If you do not see the same on nRF52840 DK, then it most likely is related to your hardware. Check if the GPIO pins selected are too close to the RADIO or antenna pins.
2. The priority of the ISR of the PDM might be too high interfering with the BLE activity which is not allowed by the softdevice. 

[brianatcarrot]

1. Unfortunately, we aren't able to reproduce this on the DK. We're also unable to reproduce it on the majority of our custom boards. The boards that are affected do it consistently, so it appears to be some kind of hardware issue. We've been unsuccessful in tracking it down so far. The traces for the PDM lines on our custom board are far enough away from the RADIO and antenna pins that they don't seem like they should cause any interference. The datasheet doesn't mention anything about not using 0.24 and 0.25 for high frequency signals.
2. The priority of the ISR of the PDM is set to the lowest priority, which is also the default priority from the SDK.

[Susheel Nuguru]

Brian,

I do not see any special requirements on 0.24 and 0.25 pins eithers, so it pretty much looks looks like an hardware board related issue on your end. 

Since you are not able to replicate this on DK or most of your other boards, I do not think this is firmware related.

[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.