I2C issue with update over the air

RE: I2C issue with update over the air

Alireza Asvadi — Tue, 16 Dec 2025 16:05:30 GMT

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

RE: I2C issue with update over the air

Hung Bui — Mon, 15 Dec 2025 14:50:40 GMT

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 ?

RE: I2C issue with update over the air

Turbo J — Sun, 14 Dec 2025 12:39:28 GMT

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.

RE: I2C issue with update over the air

Alireza Asvadi — Sun, 14 Dec 2025 03:10:39 GMT

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.

RE: I2C issue with update over the air

Alireza Asvadi — Sat, 13 Dec 2025 23:27:47 GMT

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

RE: I2C issue with update over the air

Turbo J — Sat, 13 Dec 2025 07:13:24 GMT

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.

RE: I2C issue with update over the air

Alireza Asvadi — Fri, 12 Dec 2025 23:17:09 GMT

Hi again,

I just noticed that when I enable CONFIG_BT_PERIPHERAL = y, this issue appears.

RE: I2C issue with update over the air

Alireza Asvadi — Fri, 12 Dec 2025 20:23:47 GMT

I have the same DTS in the bootloader and main app.

RE: I2C issue with update over the air

Alireza Asvadi — Fri, 12 Dec 2025 20:16:02 GMT

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

RE: I2C issue with update over the air

Turbo J — Fri, 12 Dec 2025 18:45:33 GMT

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.

RE: I2C issue with update over the air

Alireza Asvadi — Fri, 12 Dec 2025 18:17:09 GMT

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?

devzone.nordicsemi.com/.../OTA-enabled-boot.sal devzone.nordicsemi.com/.../OTA-disabled-boot.sal

RE: I2C issue with update over the air

Alireza Asvadi — Fri, 12 Dec 2025 15:24:39 GMT

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.

devzone.nordicsemi.com/.../OTA-enabled.sal devzone.nordicsemi.com/.../OTA-disabled.sal

RE: I2C issue with update over the air

Hung Bui — Fri, 12 Dec 2025 08:00:44 GMT

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 ?