ModbusMaster blocks OTA updates


#1

when using the ModbusMaster library, if I am doing intense RS485 IO, and then happen to do an OTA update, the update fails and it requires a hardware reset. This happens either when using System Thread_Enabled and Semi_automatic mode, or default operation.
Is there a way to avoid this? If useful, I am happy to provide my code, but please remind me how to include so it looks nice. Thanks


#2

OTA updates require a stable, fast connection which can be tricky if you have other operations demanding many clock cycles from the controller.
If you can accept this you can just put the device in Safe Mode before you do the OTA update.
Otherwise you could add some code that checks for incoming OTA updates and on detection stop all other tasks and enter a tight Particle.process() loop.


#3

is the best way to do that to use a System.updatesPending and then just pause my Modbus communication? I was a bit confused by the disclaimer that the updatePending doesn’t work as expected. Thanks


#4

This looks similar to my recent post.

Do you happen to have a TCP connection of some kind open? My application isn’t do as intense IO as it sounds like yours is, but might have similar impact.

But to your latest question, if you check for System.updatesPending() often enough, yes that should work. Otherwise, the firmware_update or firmware_update_pending System Events might be of interest.


#5

thanks. The only wifi connection is publishing relatively infrequent MQTT events. I will institute the checks suggested and see how that goes.


#6

@agard FYI most MQTT implementations use TCP, and my post showed that an open TCP connection (aka an MQTT connection that is still open, eg client.isConnected() == true, seems to consistently cause problems with OTA updates. You very well may need to institute my temporary solution of turning of OTA updates on bootup and then use a cloud function to turn them back on, where the cloud function shuts down MQTT until the device restarts again or the cloud function is called again.


#7

thanks!