It is difficult to tell which mode you are talking about without including all you code!
Recommended approach is to use SYSTEM_THREAD(ENABLED); and I typically use SYSTEM_MODE(SEMI_AUTOMATIC); but then you need to turn on modems and connect. Selecting and using external antennas is also a good idea.
Also, it is advisable to use a send buffer such as PublishQueueAsyncRK library that will buffer in retained RAM the cloud publishes and that way enables the loop to keep up a good cadence. I would be tempted to replace use of delay(2000); with a timer check if (millis() - lastCheck > 2000) { lastCheck = millis(); your scan code}
You would also not set BLE.setScanTimeout() repeatedly.
The local device should remembers the setting
And since the scan results are allocated dynamically chances are that you are seeing some issue with heap fragmentation.
But to have a better “guess” knowing what you consider “instable” and “block in the firmware” would be helpful.
What is the common timeframe for the “instability” to occure?
What does the device do when it is “blocking”?
What i mean with blocking is that after 5-10 seconds dataResults become null and moreover the device begin to disconnect from network (blinking green)…
I think that the problem is related, as you rightly stated ,with the fragmentation of the heap…
I was not aware of your abundant (maybe even excessive ) use of String objects - these are contributing to heap fragmentation even more.
Try to avoid them entirely and rather use ol'-school C strings (aka char arrays).