Update over the air

[Alireza Asvadi]

Hi,

I’ve enabled OTA firmware updates in our project using MCUboot. Before enabling OTA, everything worked correctly—our firmware received interrupts on pin P1.00 from one of our TI sensors with no issues.

However, after enabling OTA (MCUboot), the interrupt on P1.00 no longer triggers. It seems the bootloader is reconfiguring or overriding this pin before jumping to the application.

Could you please help me understand why this is happening and how to prevent MCUboot from altering this pin so the interrupt works again?

Thanks,

Alireza

[Alireza Asvadi]

I just noticed that this issue only occurs when I enable SB_CONFIG_BOOTLOADER_MCUBOOT=y in sysbuild.conf

[Edvin]

Hello Alireza,

The P1.00 is by default used for UART logging for the network core. So if you are using the nRF5340 DK as a target board, the control of the P1.00 will be forwarded to the network core.

I assume you already found out how you disable this, so that the application core can control the P1.00 pin, but then it stops working after you added the bootloader. 

Since the bootloader is a separate piece of code running on the nRF5340 before the actual application starts, it will now be the one that assigns ownership of the different pins. 

So whatever you did in your application, you need to also apply to the bootloader. I assume (but it depends on the NCS version that you are using) that you disabled the pin forwarding and disabled logging over UART on your network core in the application. Most likely, this is done in <board_name>.overlay, or app.overlay, depending on how you configured your application.

Now, since you added the bootloader, you need to make sure that the bootloader does the same thing. I believe you just need to copy the removal of pin forwarding from your application into sysbuild\mcuboot\<board_name>overlay, and it will be applied there as well. Give it a go, and if it doesn't work, feel free to zip and upload your application here, so that I can have a look at how you did it in the first place, and how to make the same apply to your bootloader.

Best regards,

Edvin

[Alireza Asvadi]

It worked. Thanks for your help, Edvin

[Alireza Asvadi]

Hi Edvin,

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.

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

Thanks,

Alireza

[Alireza Asvadi]

Hi Again,

I just noticed that, enabling CONFIG_NCS_SAMPLE_MCUMGR_BT_OTA_DFU, in (const struct device *i2c_dev;) i2c_dev parameters change, they have different values. I mean, i2c_dev.name, i2c_dev.config, ........ after enbaling,