Using PDM causes BLE connection to drop

RE: Using PDM causes BLE connection to drop

jrowberg — Thu, 30 Nov 2023 19:24:18 GMT

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

RE: Using PDM causes BLE connection to drop

brianatcarrot — Thu, 30 Nov 2023 18:13:09 GMT

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?

RE: Using PDM causes BLE connection to drop

jrowberg — Thu, 30 Nov 2023 03:15:58 GMT

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.

RE: Using PDM causes BLE connection to drop

brianatcarrot — Wed, 26 Jul 2023 16:21:34 GMT

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.

RE: Using PDM causes BLE connection to drop

Susheel Nuguru — Mon, 15 May 2023 11:31:06 GMT

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.

RE: Using PDM causes BLE connection to drop

brianatcarrot — Fri, 12 May 2023 16:31:40 GMT

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.
The priority of the ISR of the PDM is set to the lowest priority, which is also the default priority from the SDK.

RE: Using PDM causes BLE connection to drop

Susheel Nuguru — Fri, 12 May 2023 10:01:14 GMT

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

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.
The priority of the ISR of the PDM might be too high interfering with the BLE activity which is not allowed by the softdevice.