Preventing GPIO input when doing an OTA

[Mike Austin (LPI)]

In my firmware, I am monitoring a GPIO pin state to decide:

1. when to exit Hibernate mode and start running the firmware
2. when to stop running the firmware and re-enter Hibernate mode

I am also allowing the option to do an FOTA via BLE.

During testing, I am noticing that sometimes, during the FOTA, my device will decide that it doesn't want to be in "active" mode and will attempt to go back into Hibernate mode halfway through the FOTA, which causes things to crash.  I notice it happens whilst the new image is being uploaded.

So, I want to be able to prevent my hardware from checking the state of the relevant GPIO whilst its doing a FOTA, and only look at the state of this pin once its all completed and has rebooted and switched over to the new image. I  can probably use a mutex lock/unlock to achieve this, but I'm just not sure where in my firmware this needs to go.  As I understand it, all the FOTA is handled by the SMP Server/MCUmgr but I'm not sure I can go modifying that code.

I'm already setting the following in my mcuboot.conf file.

CONFIG_GPIO=n

Can anyone give me some ideas on how I can fix this problem?

Thanks and regards,

Mike

[AHaug]

Hi,

During testing, I am noticing that sometimes, during the FOTA, my device will decide that it doesn't want to be in "active" mode and will attempt to go back into Hibernate mode halfway through the FOTA, which causes things to crash.  I notice it happens whilst the new image is being uploaded.

It will be hard to pin down the cause when it only happens sometimes.

As a starter I'm curious to how you monitor the GPIO w.r.t when the image upload is done? Another thought is that the image upload terminates due to loss of BLE connection. Have you verified that the connection does not drop at any point? Could you add some logging to the DFU procedure in your project and monitor when and where it breaks?

Could you have a look at any relevant sample in this repository and compare it to your own project to exclude any differences? https://github.com/hellesvik-nordic/samples_for_nrf_connect_sdk/tree/main/bootloader_samples There are minimal smp samples here that should be relevant in showcasing how a typical NCS FOTA procedure works

Let me know about these initial things and I will get back to you! 

Kind regards,
Andreas

[Mike Austin (LPI)]

Hi Andreas,

Sorry - I should have provided a bit more detail in my original post.

My design spends 99.9% of its time in hibernate mode.  On the hardware, there is a reed relay, and when a user places a magnet in the specified location, this triggers a GPIO signal, which in turn triggers the device out of Hibernate mode.

This then makes my device start advertising, and our App can read the Scan Response packet to get the current status of the device, or it can connect to it to do various things: download a log of events, update the firmware, get the Silicon ID, etc

Whilst the device is active, its constantly monitoring the GPIO connected to the reed relay.  Whilst that GPIO remains active, the device remains in SYSTEM ON mode.  The moment it detects that the pin has gone inactive, it returns to Hibernate mode.

The problem we have seen in initial testing is that the magnet can move, or get knocked, and if it moves enough, its no longer activating the reed relay and the device then goes into Hibernate mode.  This is generally not a problem, but if our device is in the middle of downloading a new firmware image and the magnet is moved, then it will crash out.

What I want to do is ensure that, whilst the FOTA is active, the device will remain in SYSTEM ON mode, regardless of what the magnet is doing.  Then, when the FOTA has completed and the device resets, it will check the status of the relevant GPIO and either start up in SYSTEM ON mode, or return to Hibernate mode.

I've sort of got a solution at the moment, where I make a call to bt_conn_ref() to get the active BLE connection, and then check if that is not NULL before I decide to go back into Hibernate mode.  If its not NULL, it means there is an active BLE connection and I stay in SYSTEM ON mode regardless of whether the magnet is there or not (I've got a timeout function included in case something happens, and so it will automatically return to Hibernate mode after about 5 mins to save battery).  I'd like to have a system whereby if the magnet is removed, it will return to Hibernate only if there is no actual data being received over BLE, rather than just if its currently connected to a Central.  But I'm not sure if that's possible, and how I would check if the SMP Server was still downloading the new image file.

I'll have a look through those examples you included the link for

Regards,

Mike

[Sigurd Hellesvik]

Hi Mike,

Andreas is going on vacation, so I will continue to help with this case.

mcumgr code has changed a bit over the last releases, so before I start digging: which nRF Connect SDK version would you like to find such a callback for?

Regards,
Sigurd Hellesvik

[Mike Austin (LPI)]

Hi Sigurd,

im currently using NCS v2.2.0, but am happy to upgrade to a newer version if it makes things easiet

Regards,

Mike

[Sigurd Hellesvik]

I think CONFIG_MCUMGR_MGMT_NOTIFICATION_HOOKS could be what you need:

"With this enabled, applications and parts of code can register for MCUmgr event notifications which will result in callbacks when a registered event occurs."
Looks like this one is available for v2.3.0 and up.

For more options for MCUMGR hooks, search the Kconfig search for "MCUMGR.*HOOK"

I would love to try out this myself and give you a sample, but we have limited staff due to summer vacations, so you will have to figure out how to do this yourself.
Let me know if you face any trouble along the way.

Regards,
Sigurd Hellesvik