I2C issue with update over the air

[Alireza Asvadi]

Hi,

We are using a TMD2636 proximity sensor on our board, connected via I²C on pins P0.18 (SDA) and P0.30 (SCL). The same I²C bus also contains a TMP117 temperature sensor and another device.

Before enabling OTA updates, all sensors work correctly. However, after enabling:

CONFIG_NCS_SAMPLE_MCUMGR_BT_OTA_DFU=y

The proximity sensor (TMD2636) stops responding, while the TMP117 and the other sensor continue to operate normally on the same bus.

I checked the I²C pulses with a logic analyzer and confirmed that the TMD2636 no longer sends an ACK after OTA support is enabled.

These are two screenshots from Digital Analyzer, when I enable CONFIG_NCS_SAMPLE_MCUMGR_BT_OTA_DFU=y, as you see, the proximity sensor doesn't send ACK:

But when I disable the CONFIG_NCS_SAMPLE_MCUMGR_BT_OTA_DFU=n, the proximity sensor starts to send ack,

Could you please advise on what might cause this issue or how I can resolve it?

Thanks,

Alireza

[Alireza Asvadi]

 Hi Hung Bui,

I wrote another simple test program to simulate those two unwanted pulses. When the I2C peripheral is enabled, I lose direct control over the GPIOs on the I2C bus, so for testing, I used a basic GPIO library to manually generate similar pulses on P0.18 and P0.30.

First, regarding the TMD2636 proximity sensor: it uses the very first I2C command only to configure its I2C address. It does not respond to that command; it only starts acknowledging from the second command. In other words, the first command is essentially a dummy write used for initialization.

In the first screenshot (no extra pulses), the sensor behaves correctly — it sends an ACK right after the first dummy command, and it continues acknowledging from the second command as expected.

In the second screenshot, I added two pulses identical to the ones generated when OTA is enabled. As you can see, when those two pulses occur, the sensor gets stuck and never sends any ACK.

My question is: when OTA is enabled, how can I prevent those two pulses on the I2C lines during boot?

Thanks,

Alireza

[Turbo J]

SCL analog curve looks terrible - I am surprised that this works at all. SDA analog curve does not look anywhere close to the digital near those "spikes".

Do you have external pullup resistors on the bus? The internal pullups in NRF chips are a little too small for proper I²C bus operation.

[Alireza Asvadi]

Hi Thanks you for your response,

No, we don’t have external pull-up resistors, and it’s difficult to add them at this stage. I tried using gpio-hog in my DTS—both in the main application and in the MCUboot DTS—but it did not work. Do you know why this might be happening?

Thanks,

Alireza

[Alireza Asvadi]

I have another question: is it possible to enable CONFIG_BT_PERIPHERAL at runtime? We need this feature for our device, but when it is disabled, the unwanted pulses disappear. My thought was to disable it in the configuration file and enable it later at runtime to see if that would resolve the issue.

[Turbo J]

Redesign.

The bus will go high impedance during device resets and work as an antenna, there is NOTHING you can do to prevent that here. Software will only run after hardware reset procedure finishes.

You could try running i2c_recover_bus() at app start before communicating with the device. Should un-block the bus if the device was stuck in a random bus state.

[Hung Bui]

Hi Alireza, 
I would suggest to check if  you have used the internal pull up on the pin or not. 
You should also try to find a sequence that can reset the I2C device. Does it have a reset pin ?  
I am not so sure why enabling CONFIG_BT_PERIPHERAL  would trigger the pulses.  
Could you let me know what kind of reset used in the test ? Was it pin reset or power reset or softreset ? 

[Alireza Asvadi]

Hi Hung,

Thank you for your reply. I have resolved the issue by disabling the external flash, which corrected the behaviour. When the external flash is enabled, additional pulses appear on the SDA line, and these pulses interfere with the sensor’s operation

Thanks,

Alireza