SPI transfers cause BLE connection timeout, but only on some units and especially when cold?

RE: SPI transfers cause BLE connection timeout, but only on some units and especially when cold?

jrowberg — Fri, 01 Dec 2023 15:00:13 GMT

I had not tried the RC option, because early on (in desperate random troubleshooting) I encountered errors when switching to it, and then tried HFCLK instead with apparent success. However, I've just changed to RC, and it appears to be reliable as well. I've held a connection for 10 minutes with no data transmission problems so far, and I'll keep letting it run for an extended test. Thanks for the tip! This will be much better than HFCLK if it keeps working.

For what it's worth, here's a data point for you concerning the synthesized-from-HFCLK source: I left our "bad" device connected and transmitting data overnight with the SYNTH config, and it stayed 100% solid, delivering over 140 MB of dummy data over BLE in about 12 hours. This is the same unit that couldn't stay connected for 1 second with the XTAL input, otherwise the same config (including running 2MHz SPI over officially unrecommended pins near the radio).

RE: SPI transfers cause BLE connection timeout, but only on some units and especially when cold?

Jørgen Holmefjord — Fri, 01 Dec 2023 10:59:29 GMT

[quote user="jrowberg"]A design change isn't in the cards for the immediate future, so it looks like I need to figure out the least painful way to rely on the HFCLK during connections at this point.[/quote]

Have you checked if the LFRC clock source eliminates the problem similar to LFSYNT? This is the clock source that is normally used in designs that does not include a crystal. The current consumption of LFRC is slightly higher than LFXO due to calibration towards HFCLK and window widening in connections from worse tolerance, but it is far from the current used by LFSYNT. LFSYNT is also not well tested and is not recommended for use with the SoftDevice.

RE: SPI transfers cause BLE connection timeout, but only on some units and especially when cold?

jrowberg — Fri, 01 Dec 2023 02:56:22 GMT

Wow, that's...really important to know, and I totally missed it during the design phase. Particularly the P1.15 clock speed limitation. Clearly, some revisions are in order if we want to follow the design guidelines more closely.

I tried shorting the 1k series resistor, and it didn't result in any improvement. Nuts.

Oddly though, despite this note in the datasheet, that pin seems to have no problem driving the IMU's SPI interface at 2MHz.We've got nearly a year of testing with about a hundred of these all over the place, and nobody's complained about bad data (ever) or this connection issue (until very recently).

However, I'm still confused about why simply changing the temperature would have such a dramatic effect on whether it happens. Similarly, why does switching the LFCLK source to be synthesized from the HFCLK eliminate the issue as well? If the problem is interference between a misallocated I/O pin and the radio, shouldn't that still cause the issue to occur while the IMU is busily passing data along? Maybe the at-risk signals only concern a non-synthesized clock.

A design change isn't in the cards for the immediate future, so it looks like I need to figure out the least painful way to rely on the HFCLK during connections at this point.

Thanks for your help!

RE: SPI transfers cause BLE connection timeout, but only on some units and especially when cold?

hmolesworth — Fri, 01 Dec 2023 02:05:34 GMT

I looked at the BMD340 and the SCK and Osc pins are pretty close together, plus the P1.15 SCK is unsuitable for any kind of SPI clock; it is close to the radio and will affect as well as be affected by transmissions. So .. the fix - if shorting the 1k doesn't work - may well be to use an unrestricted P0.nn i/o pin for SCK (and probably MOSI and MISO as well). (Duplicated to avoid losing text)

RE: SPI transfers cause BLE connection timeout, but only on some units and especially when cold?

hmolesworth — Thu, 30 Nov 2023 20:03:56 GMT

Looks correct; however I would try shorting out the 1k0 series resistor and see if there is any change. A periodic check in the firmware for the contents of LFCLKSRCCOPY and LFCLKSRC and LFCLKRUN would also be a good idea ..

.. I should add that with a 1k0 resistor the high-impedance nRF52840 clock input pin will experience more interference from a high-speed clock source such as SPI ..

Edit: I looked at the BMD340 and the SCK and Osc pins are pretty close together, plus the P1.15 SCK is unsuitable for any kind of SPI clock; it is close to the radio and will affect as well as be affected by transmissions. So .. the fix - if shorting the 1k doesn't work - may well be to use an unrestricted P0.nn i/o pin for SCK (and probably MOSI and MISO as well).

WLCSP Port  BMD340 Function
===== ===== ====== =======================================================================================
B9    P0.00 Pin 13 XL1 Digital I/O Analog input General purpose I/O Connection for 32.768 kHz crystal
B10   P0.01 Pin 14 XL2 Digital I/O Analog input General purpose I/O Connection for 32.768 kHz crystal
C6    P1.15 Pin 64 Digital I/O General purpose I/O Standard drive, low frequency I/O only. Close to radio

RE: SPI transfers cause BLE connection timeout, but only on some units and especially when cold?

jrowberg — Thu, 30 Nov 2023 19:17:22 GMT

[quote userid="14926" url="~/f/nordic-q-a/106208/spi-transfers-cause-ble-connection-timeout-but-only-on-some-units-and-especially-when-cold/458247"]How exactly is the LFCLK source configured in your application? The SoftDevice does not have any option for configuring external clock source, but if clock is configured and started by the application before the SoftDevice is enabled, the EXTRENAL/BYPASS configuration should not be overridden.[/quote][quote userid="65515" url="~/f/nordic-q-a/106208/spi-transfers-cause-ble-connection-timeout-but-only-on-some-units-and-especially-when-cold/458223"]Can you provide details of the TCXO and an accurate scope (not logic analyser) trace of the TCXO waveform at the nRF52?[/quote]

Thanks for your replies, and my apologies--I've updated the original post with more detail about the part. It's SIT1552AI-JE-DCC-32.768E, specifically chosen for the rail-to-rail full swing and extra high accuracy. We have not requested or configured a non-standard VOH/VOL value, so my understanding (and intent, and measurement) is that it's simply GND to VCC. Note, VCC in this circuit is 3.1V.

The TCXO clock output is connected to P0.00 (XL1) through a 1K series resistor. (The signal appears to be the same on both sides of this resistor). P0.01 (XL2) is left floating. The LFCLKSRC register is configured at the top of the bootloader's main() function to full-swing mode (EXTERNAL + BYPASS bits as defined in nrf_clock.h):

// configure LFCLK if necessary
if (!nrf_clock_lf_is_running())
{
    // set LFCLK source to external full-swing clock
    NRF_CLOCK->LFCLKSRC = NRF_CLOCK_LFCLK_Xtal_Full_Swing;
}

It checks to make sure the clock isn't running first because sometimes the app jumps back to the bootloader for DFU. The same conditional configuration block of code is in the application's main() function as well, as I've currently been using an app-only firmware image for simpler/faster testing and debugging in Segger Embedded Studio + J-Link.

The bench tools I currently have available are a Saleae Logic Pro 16 (digital + analog) and a Tektronix TBS 1052B digital oscilloscope, neither of which is the world's best clock measurement tool, but here's what I get:

Both devices show basically what I expect to see, though the rails aren't quite touched according to the Tektronix scope--just close. There is also a fairly large variance in what the Saleae shows for the actual clock period. The screenshot highlights a detected frequency that is exactly correct, but the analyzer reports a range of 32688 up to 32860 Hz. I suspect a measurement issue rather than a signal issue because (1) the Tektronix unit is much more stable and (2) one of our devices that works fine with a stable connection yields the same varied measurement on the Saleae device.

If there is a specific tool I need to capture this better, let me know; I might be able to get one.

I'm intrigued by the possibility of measuring the TCXO against the 32 MHz clock, and may dig into this. Another question is whether it could be possible to switch clock sources at runtime for power-saving purposes. The increased consumption of the HFCLK is dwarfed by the power draw of active components like the BLE radio and IMU during normal active use of our device, so it would be acceptable to use the HFCLK for BLE connection timing and drop back to the LFCLK for extended sleep (minutes/hours) in between usage events.

Speaking of temperature dependence (which clearly impacts the behavior in my case), here are three more data points:

1. I tried the most aggressive clock setting (20ppm accuracy) and then used a hot air gun to slowly raise the temperature of the whole board up to about 70 deg. C. This allowed a solid connection with full IMU use and data transmission for five minutes, which is when I stopped the test

2. I then tried putting a small plastic bag with some crushed ice directly on the test device to force it to misbehave. Starting from the warm state, it retained the connection for another four minutes before it timed out. Reconnecting immediately allowed another semi-stable connection, lasting 50 seconds that time. Reconnecting again only lasted about 10 seconds, clearly getting progressively worse as the temperature dropped.

3. I let the ice sit on it for another 30 minutes until it was much colder than usual, at which point not only would it immediately disconnect after connecting + starting the IMU, but the small double-beep disconnection tone was sluggish and drawn out. This is an audible signal we generate via PWM into a piezo element (low-side transistor switch, not direct), implemented using the "app_pwm" driver. By "sluggish," I mean that the tone's pitch was correct but it's supposed to be two 100ms beeps with a 100ms gap between, and all three of those durations were more like 1500ms. So, the app timer ticks got way slower somehow, presumably because they're driven by the LFCLK as well. But the LFCLK definitely hadn't dropped down to 10kHz or 3kHz or something, or the whole system would have fallen apart.

I'm still confused.

RE: SPI transfers cause BLE connection timeout, but only on some units and especially when cold?

hmolesworth — Thu, 30 Nov 2023 13:52:10 GMT

Following up on my reply yesterday, often issues regarding suspected loss of timing for the BLE transactions can be determined by adding a self-test of the external 32kHz clock to alert when that clock input behaves unexpectedly. This can be done by deriving a time interval from one of the RTC CC conditions, either dedicated or simply leveraged off an existing CC, and deriving a comparable interval from a known-good timing reference. For testing, the known-good timing reference can use the nRF52840 32MHz crystal, although that has to be kept running during the tests which increases power consumption. Another comparison source is to derive a known interval from the external EMU, which although using the same TCXO is likely to behave differently than the nRF52840. The EMU keeps internal time, though reading that out might require some creative thinking although datasheet does state "Timestamps attached to sensor reports". If using a fixed update rate triggered by the EMU, simply using the Packet Sequence Number from the EMU would give an interpreted accurate timing source which would be compared with the nRF52840 RTC providing continuous monitoring. As an aside, make sure the 'scope probes are set to 10x and are calibrated before providing the waveform as mentioned in my other reply.

RE: SPI transfers cause BLE connection timeout, but only on some units and especially when cold?

Jørgen Holmefjord — Thu, 30 Nov 2023 09:47:53 GMT

Hi,

How exactly is the LFCLK source configured in your application? The SoftDevice does not have any option for configuring external clock source, but if clock is configured and started by the application before the SoftDevice is enabled, the EXTRENAL/BYPASS configuration should not be overridden.

Also, make sure you use the correct mode (Low swing/Rail-to-rail configuration) for your external clock source.

Best regards,
Jørgen

RE: SPI transfers cause BLE connection timeout, but only on some units and especially when cold?

hmolesworth — Thu, 30 Nov 2023 07:12:54 GMT

Can you provide details of the TCXO and an accurate scope (not logic analyser) trace of the TCXO waveform at the nRF52? The LFCLK external input is very piccy, and the timing may well be affected by the input voltage levels which in turn may be affected by the SPI transfer disturbance coupling to Vdd on either the TCXO or the nRF52840. What has the customer-specific TCXO output voltage been set to, and does it match the nRF52840? If not then coupled noise becomes more critical.

nRF52840: "VAMP,IN,XO,LOW Peak to peak amplitude for external low swing clock. Input signal must not swing outside supply rails. min 200 max 1000 mV"

SiT1552: The SiT1552 has two output voltage options. One option is a standard LVCMOS output swing. The second option is the NanoDrive reduced swing output. Output swing is customer specific and programmed between 200 mV and 800 mV. For DC-coupled applications, output VOH and VOL are individually factory programmed to the customers’ requirement"

Also which nRF52840 external clock input option is being used:

"The following external clock sources are supported:
- Low swing clock signal applied to the XL1 pin. The XL2 pin shall then be grounded. set BYPASS=0
- Rail-to-rail clock signal applied to the XL1 pin. The XL2 pin shall then be grounded or left unconnected" set BYPASS=1