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

[Hung Bui]

Hi Alireza, 
I suspect that my enabling CONFIG_NCS_SAMPLE_MCUMGR_BT_OTA_DFU you may have enabled external flash which use pin P0.18 as CS pin. 

Could you try a quick test to use other pins for the TMP117  ? 
Also could you record a longer trace to see if there is other activity on SCL, SDA  when the chip boot up ? 

[Alireza Asvadi]

Hi Hung Bui,

Thanks for your response, 

Because the PCB is already designed and manufactured, we cannot change the GPIO routing on our board. However, I tested the same firmware on the Nordic development kit using different I²C pins, and it works correctly with those alternate pins. As I mentioned earlier, we have two other sensors on the same I²C bus, and they both work fine regardless of whether OTA is enabled or disabled.

I will send you the SAL file that can be opened with Saleae Logic Analyzer, and I’ve also attached the screenshots. In case you cannot open the (.sal) file, the screenshots clearly show the issue:

With OTA enabled, previous I²C transactions on the bus receive proper ACKs, but the proximity sensor (I²C address 0x39) does not acknowledge.

With OTA disabled, the TMD2636 receives and returns the expected ACK.

From my perspective, if this GPIO pin were actually being used or overridden by OTA, then all sensors on the bus should stop working. However, the other two sensors continue to communicate normally, which makes the issue more confusing.

OTA enabled.salOTA disabled.sal

[Alireza Asvadi]

Hi again,

 

I am using a very simple program that repeatedly reads the proximity sensor’s device ID. During testing, I noticed that when OTA is enabled, there are two unexpected pulses on the I²C lines during the boot sequence. These pulses appear before my application starts and may be causing the proximity sensor to enter a bad state. When OTA is disabled, these pulses do not appear at all.

I have attached the .sal file from the logic analyzer for reference.

My question is: How can I prevent or eliminate these pulses during the boot phase when OTA is enabled?

OTA enabled boot.salOTA disabled boot.sal

[Turbo J]

Check config and DTS in your bootloader. You probably need a custom overlay for mcuboot.

The sample code pulls a ton of stuff in by default including QSPI  IIRC.

[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