Electron: how to freeze with solid cyan/green

Hello everybody,

I’m currently stuck with 50+ 3G Electron EU presenting the same problem: “frozen” with solid cyan or green led.

  • On places with a good cell coverage, no problem for h24 use 7 days a week.
  • On places with a bad network and/or switching 2G-3G, the problem is unavoidable in less than an hour.

I need new insights to resolve the problem so I’ll “reverse it”.

Can you give me a code example (or more!) that freezes the electron in this state?

Thanks!

Do these devices exhibit the same behavior when running something extremely simple like “Blink an LED” or Tinker? If not, then your code would be an example of the issue you’re describing.

What an unlikely request :wink:
Usually people want to avoid that kind of behaviour. However, even if we’d provide you with some code that would result in such a deadlock it wouldn’t help you a lot since plenty other coding errors could cause that too.

The common denominator for such issues is usually the application code requesting a shared resource (e.g. HW interface) while the Device OS also wants to use it.

For the last two weeks I have been reading docs, “Troubleshooting” threads, cleaning my code looking for a shared blocking ressource… I need something new!
Even enumerating the list of potential problems would be great!

  • waiting for a ressource to be available? Do you have an example, even stupidly simple, without waitfor?
  • stack/heap problem? Causing red flashes is likely but a solid led?
  • multiple interrupt with different priorities?
  • blockOnOverrun?

A list of things to avoid (to look for in my case) is useful. A sort of “In case of freeze read this” document.

I’m not familiar with FreeRTOS. I do not even know if the freeze is caused by a deadlock or by an OS crash. Can I still use ISR / HW timer / other modules when crashed? when frozen?

It might be easier to look at your code if something sticks out to us.

The problem with showing a test code is that the effect is highly timing dependent. Since you need to get into a deadlock with the system but can’t control the system when to do what, you need to hope your code wants to access to a shared resource the very moment the system wants it too. This is non-deterministic and hence hard to reproduce.

If you want to do it, it never happens (particularly when you subconciously know what not to do) - if you want to avoid it, it’s bound to happen :wink:

1 Like