Hi All,
We have few Photons that we connect to our local cloud. Our application firmware collects data from different peripheral sensors by creating multiple threads and running them in a while(1) loop with a delay of 10ms in each loop, and do the data collection and add to FIFO buffer in them. These threads are created and started during the setup(), and the data being collected is processed.
However, in such a scenario, the OTA of the firmware fails. The command goes through and we can see the magenta color on the device, but the application firmware changes do not reflect and the devices keeps running the previous application firmware (and not the one we push).
Is this a known issue where OTA does not work when application firmware create looping multiple threads?
Thanks
I wonder if it’s a local 
issue. How are you compiling the firmware into a binary?
Be sure to check that the user firmware is compiled with a system firmware <= to system firmware on the particle device.
@abhijit, running several threads might be interfering with the system thread if you are running the threads at too high a priority. Are you using interrupts for sampling data? Are the FIFOs handled in the user application thread?
As @kennethlimcp indicated, is your system firmware matching your user application firmware version? If not, the cloud will attempt to update the system firmware via OTA.
@peekay123, yes, that’s very much possible. No, we are not using interrupts for sampling data. Yes, the FIFOs are handled in the main user application.
Can this be solved by killing the threads whenever an OTA is sent? Is there a callback function that can be run in user-application so that we can write the logic to kill the threads before OTA proceeds?
@abhijit, take a look at system events. A forum search on OTA pending might also bring up valuable info.
RTOS threads are not to be killed.
You can use a flag to have it not do anything but idle tho’ - possibly yielding control back to RTOS.