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

[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]

Good morning Advin,

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,

 

[Edvin]

Hello,

Sorry for the late reply. We have had some issues with DevZone lately. 

That seems odd. The signals coming from the nRF53 seems identical in both cases. They have the same output voltage, I presume?

Is there any other parts of the I2C traffic that seems different after you enable the DFU? Could it be something during the init sequence that doesn't happen after you enable DFU? You mentioned that the i2c_dev.name and i2c_dev.config changed What does it look like, before and after? These should be compile time variables.

Best regards,

Edvin

[Alireza Asvadi]

Hi Edvin,

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