# System Thread Enable is not working **URL:** \ **Category:** Firmware\ **Tags:** electron\ **Created:** [March 14, 2019, 7:29pm UTC](https://community.particle.io/t/system-thread-enable-is-not-working/48427 "2019-03-14T19:29:13Z")\ **Posts on this page:** 15\ **Page:** 1
**Author:** ![d.chauhan](https://sea2.discourse-cdn.com/flex026/user_avatar/community.particle.io/d.chauhan/32/19161_2.png) [@d.chauhan](https://community.particle.io/u/d.chauhan)\ **Post date:** [March 14, 2019, 7:29pm UTC](https://community.particle.io/t/system-thread-enable-is-not-working/48427/1 "2019-03-14T19:29:13Z")
Hey All, I want to use **SYSTEM\_THREAD(ENABLED);** to keep background application loop running all the time. My main **loop()** function reads data from serial port. Everything works fine when the cellular signal is available. But when the cellular signal goes off (LED blinks green on the electron), the **loop()** function is getting blocked. And it stops reading data from serial. How can i make loop function running all the time to read data from serial?? I added the following line at the top of the code: **SYSTEM\_THREAD(ENABLED);** But it is still blocking the **loop()** function. Where should i put **SYSTEM\_THREAD(ENABLED);**?? 1. Inside **setup()** function 2. Outside **setup()** function 3. Where??? Thank you in Advance ---
**Author:** ![peekay123](https://sea2.discourse-cdn.com/flex026/user_avatar/community.particle.io/peekay123/32/810_2.png) [@peekay123](https://community.particle.io/u/peekay123)\ **Post date:** [March 14, 2019, 7:51pm UTC](https://community.particle.io/t/system-thread-enable-is-not-working/48427/2 "2019-03-14T19:51:11Z")
@d.chauhan, you placement is correct (outside both setup() and loop()). However, if you are not checking for cloud connectivity (eg. `Particle.connected()`) prior to call Cloud functions, the code may block. So, your loop() code needs to be connection “aware”. One approach is to run in SEMI\_AUTOMATIC mode and have your code decide when it connects vs not. ---
**Author:** ![d.chauhan](https://sea2.discourse-cdn.com/flex026/user_avatar/community.particle.io/d.chauhan/32/19161_2.png) [@d.chauhan](https://community.particle.io/u/d.chauhan)\ **Post date:** [March 14, 2019, 8:22pm UTC](https://community.particle.io/t/system-thread-enable-is-not-working/48427/3 "2019-03-14T20:22:27Z")
It still blocks the serial port and loop. The partial code is below: ```auto #include "Particle.h" SYSTEM_THREAD(ENABLED); SYSTEM_MODE(SEMI_AUTOMATIC); void setup() { // GPIO enable // Particle.publish(some data); } void loop() { Cloud::loop(); // Reads data from serial and publish it if (!Particle.connected() || Cloud::rssi < -120){ Particle.connect(); status(LED::red); } else if (Cloud::rssi < -90) { status(LED::yellow); } else { status(LED::green); } } ``` ---
**Author:** ![ninjatill](https://sea2.discourse-cdn.com/flex026/user_avatar/community.particle.io/ninjatill/32/17370_2.png) [@ninjatill](https://community.particle.io/u/ninjatill)\ **Post date:** [March 14, 2019, 10:37pm UTC](https://community.particle.io/t/system-thread-enable-is-not-working/48427/4 "2019-03-14T22:37:24Z")
> [@d.chauhan](#): > > Cloud::loop(); What happens in this function? Is the publish in this function wrapped in a `if (particle.connected())` block like @peekay123 suggests? ---
**Author:** ![joel](https://avatars.discourse-cdn.com/v4/letter/j/b9bd4f/32.png) [@joel](https://community.particle.io/u/joel)\ **Post date:** [March 15, 2019, 3:48am UTC](https://community.particle.io/t/system-thread-enable-is-not-working/48427/5 "2019-03-15T03:48:15Z")
`Cloud::loop(); // Reads data from serial and publish it` This will be your problem. Publish depends on the system thread and is potentially blocking, especially in instances where the Particle cloud connection is not available. @rickkas7 developed a library you may find helpful at [https://github.com/rickkas7/PublishQueueAsyncRK](https://github.com/rickkas7/PublishQueueAsyncRK) ---
**Author:** ![joel](https://avatars.discourse-cdn.com/v4/letter/j/b9bd4f/32.png) [@joel](https://community.particle.io/u/joel)\ **Post date:** [March 15, 2019, 3:52am UTC](https://community.particle.io/t/system-thread-enable-is-not-working/48427/6 "2019-03-15T03:52:32Z")
Wrapping publishes in `Particle.connected()` is helpful but not sufficient protection against blocking. It normally takes an initial failing publish (which can block) for the cloud connection to drop. ---
**Author:** ![armor](https://sea2.discourse-cdn.com/flex026/user_avatar/community.particle.io/armor/32/18398_2.png) [@armor](https://community.particle.io/u/armor)\ **Post date:** [March 15, 2019, 11:03am UTC](https://community.particle.io/t/system-thread-enable-is-not-working/48427/7 "2019-03-15T11:03:38Z")
Can you please explain > Wrapping publishes in Particle.connected() is helpful but not sufficient protection against blocking I am having a problem tracking down an issue on a photon where the device sometimes freezes up when the wifi credentials stored are for a WAP that is out of range. Sometimes it works fine and just sails on as it should and now since 1.0.0 it sometimes doesn't. I have been relying on testing Particle.connected() as THE way to avoid calling functions that would block given there is no Cloud connection. Is there an alternative or 100% test you can recommend? ---
**Author:** ![d.chauhan](https://sea2.discourse-cdn.com/flex026/user_avatar/community.particle.io/d.chauhan/32/19161_2.png) [@d.chauhan](https://community.particle.io/u/d.chauhan)\ **Post date:** [March 15, 2019, 4:33pm UTC](https://community.particle.io/t/system-thread-enable-is-not-working/48427/8 "2019-03-15T16:33:05Z")
**Huge Success 💪** Loop for reading data from the serial is working perfectly without blocking. The cellular connection is also robust. ```auto void loop() { Cloud::loop(); if (!Particle.connected()) { Particle.connect(); status(LED::red); } } ``` The above code is managing the cloud connection in **semi\_automatic** mode. Changed the logic of publishing data inside **Cloud::loop()** **New logic** ```auto If ( particle connected) { publish data } ``` **Strange Observations** Somehow when i try to access **particle.variable** , it starts throwing **Bummer! Failed to fetch variable** error more frequently with the **semi\_automatic** mode. Also, The Ping in the particle console also fails a lot. Is there any connection of semi\_automatic mode with this issues?? Or am i handling the cloud connection wrong?? Thank you all for the help. ---
**Author:** ![ninjatill](https://sea2.discourse-cdn.com/flex026/user_avatar/community.particle.io/ninjatill/32/17370_2.png) [@ninjatill](https://community.particle.io/u/ninjatill)\ **Post date:** [March 15, 2019, 4:43pm UTC](https://community.particle.io/t/system-thread-enable-is-not-working/48427/9 "2019-03-15T16:43:33Z")
You indiscriminately call Particle.connect() every loop iteration without giving the code any time to actually connect before the next call. Why not implement a wait period? ---
**Author:** ![joel](https://avatars.discourse-cdn.com/v4/letter/j/b9bd4f/32.png) [@joel](https://community.particle.io/u/joel)\ **Post date:** [March 15, 2019, 4:44pm UTC](https://community.particle.io/t/system-thread-enable-is-not-working/48427/10 "2019-03-15T16:44:30Z")
The general model provided in [https://github.com/rickkas7/PublishQueueAsyncRK](https://github.com/rickkas7/PublishQueueAsyncRK) for off-loading potentially blocking operations (such as a `Particle.publish`) to a background thread is very useful. In my applications that have strict non-blocking requirements I will often use the main application thread, a publish thread, and third background thread to handle other potentially blocking operations. ---
**Author:** ![peekay123](https://sea2.discourse-cdn.com/flex026/user_avatar/community.particle.io/peekay123/32/810_2.png) [@peekay123](https://community.particle.io/u/peekay123)\ **Post date:** [March 15, 2019, 5:02pm UTC](https://community.particle.io/t/system-thread-enable-is-not-working/48427/11 "2019-03-15T17:02:39Z")
@joel, I sniff best practices and examples! Can you contribute some? 😉 ---
**Author:** ![armor](https://sea2.discourse-cdn.com/flex026/user_avatar/community.particle.io/armor/32/18398_2.png) [@armor](https://community.particle.io/u/armor)\ **Post date:** [March 15, 2019, 5:30pm UTC](https://community.particle.io/t/system-thread-enable-is-not-working/48427/12 "2019-03-15T17:30:34Z")
Thanks for the advice and I second what @peekay123 has requested by way of examples. I will take a look at the link. We definitely need some ‘model’ answers as to how to develop reliable connected apps. A reliable method for handling all conditions of WiFi (or cellular) comms is what I am after that does not impact the main application unduly (short or managed interrupts are OK - like at startup). I would also love to understand what situations with WiFi connection missing and where Particle.connect() would not have been called could cause a true to be returned from Particle.connected()? I am suspecting a timing issue because whenever I have the SerialLogHandler on I cannot reproduce the issue! Under the scenario I described of WiFi out of range, is it therefore best to test for WiFi.ready() and then Particle.connected() rather than just Particle.connected(). Lastly, something has changed in device OS 1.0.X from 0.8.0-RC.11 that has changed the behaviour?? ---
**Author:** ![d.chauhan](https://sea2.discourse-cdn.com/flex026/user_avatar/community.particle.io/d.chauhan/32/19161_2.png) [@d.chauhan](https://community.particle.io/u/d.chauhan)\ **Post date:** [March 15, 2019, 5:59pm UTC](https://community.particle.io/t/system-thread-enable-is-not-working/48427/13 "2019-03-15T17:59:11Z")
@ninjatill Should i add delay before calling **particle.connect()** but inside the if condition? When the cellular is working perfectly, i can see all data being published. It means that the cellular connection is fine. But at this time, ping is still failing as well as the particle.variable. How this can happen?? How can i make ping response faster? ---
**Author:** ![ninjatill](https://sea2.discourse-cdn.com/flex026/user_avatar/community.particle.io/ninjatill/32/17370_2.png) [@ninjatill](https://community.particle.io/u/ninjatill)\ **Post date:** [March 15, 2019, 9:02pm UTC](https://community.particle.io/t/system-thread-enable-is-not-working/48427/14 "2019-03-15T21:02:38Z")
I was thinking more like this from the docs: [https://docs.particle.io/reference/device-os/firmware/xenon/#waitfor-](https://docs.particle.io/reference/device-os/firmware/xenon/#waitfor-) ```auto // SYNTAX waitFor(condition, timeout); // wait up to 10 seconds for the cloud connection to be connected. if (waitFor(Particle.connected, 10000)) { Particle.publish("weather", "sunny"); } ``` Or call `Particle.connect()`, then use a millis()-based timer to wait for 10 seconds or so before calling `Particle.connect()` again. A straight-up delay is not generally good coding practice. ---
**Author:** ![rowsail](https://avatars.discourse-cdn.com/v4/letter/r/b77776/32.png) [@rowsail](https://community.particle.io/u/rowsail)\ **Post date:** [March 19, 2019, 1:37pm UTC](https://community.particle.io/t/system-thread-enable-is-not-working/48427/15 "2019-03-19T13:37:33Z")
If the project becomes larger, it might be worth writing a ‘wrapper’ function to the publish function so that the check for active connection is always made before calling the Particle publish function - that way, to do the check can’t accidentally be forgotten. Blocking appears to be such a common problem for anyone new to the Particle system - would it not make sense to put the necessary checks for avoiding blocking into the underlying library functions? For example: within ‘publish’ a check for an active/valid connection could be made and FAIL returned if unsuccessful.