BLE transmission errors when i2c sensors read in interrupt

[Yano]

Hi, we have a device that reads two sensors on separate i2c buses consecutively and transmits these using ble_nus_data_send().

The i2c sensors are read on an interrupt timer 100 readings a second.

The problem is we are dropping a lot of packets especially at the beginning of the transmission.

When we switch off the i2c sensors reading and just transmit dummy packetst he problem goes away.

We use ble_nus_data_send() to send data which is called from main and polls for sensor data.

How can the interrupt routines interfere with BLE transmissions? Are they not on higher interrupt priority?

Is there anything we can do to stop the i2c reading in interrupt interfering with BLE transmissions?

Thanks

[Jared]

Hi,

What pins are used for the I2C communication?

regards

Jared 

[Yano]

Hi Jared,

P0-30, P0-19 and P0-11, P0-31 

[Jared]

P0-30, P0.19 and P0-31 is marked as low frequency/low drive in the product specification. This means that they should not be used for serial communication, as we have seen that it can interfere with the radio. Can you try to use pins on the left side of the chip and see if it mitigate the issue?

[Yano]

Hi,

I've never seen this before, is there documentation on it?

We're only operating at 400KHz.

We're using an nRF52832 in a module ISP1507AX.

Are there similar restrictions with this?

Is there a way to mitigate this?

For example could we drop the i2c read speed?

Thanks

[Jared]

Hi,

From the documentation I linked in my previous reply:

Yes, this is relevant for all nRF52832. You can either decrease the frequency or try to schedule the I2C communication when the radio is off.

But first you should test with other pins and see if this is really the problem or not in your case.

regards

Jared 

[Yano]

Hi Jared,

We move the pins and we still have a problem.

We moved pins to the following:

P0.11 SDA0

P0.07 SCL0

P0.03 SDA1

P0.19 SCL1

None of these are on the data sheet as near the radio.

I don't know if the ISP1507AX uses a die or a WLCSP.

How can we tell what pins of the ISP can cause a radio interference problem?

We changed one of the i2c reading cycles (the one that caused the most problems) to a ppi sequence and we still have the same problem so i suspect it's not a software resources issue.

Also the ble_nus_data_send() function only sends once the two i2c senors have been read (see CH4 yellow trace).

The sensor reading now happens in parallel, one on interrupt one on ppi.

We have a loop in main waiting for a global flag indicating the sensor reading is complete. And then we call ble_nus_data_send(). Is that OK?

It's interesting that the majority of the errors come in the first few seconds and then it stabilises.

Is there a way to determine if ble_nus_data_send() is complete to prevent us from overloading it?

Thanks 

[Jared]

Hi,

Are you already in a connection when you start the first I2C transfers to retrieve the data, or does it retrieve the data while the device is advertising/establishing a connection? On a second thought, this question doesn't make sense. Nvm this point. 

The ble_nus_data_send() should be able to handle this and I don't see any issues with your method. Could you share a minimal example that reproduces this issue?

If you only use one I2C, do you still observe dropped packets? 

Yano said:

I don't know if the ISP1507AX uses a die or a WLCSP.

How can we tell what pins of the ISP can cause a radio interference problem?

The module manufacturer should specify what kind of package they are using in their documentation. 

regards

Jared