Heltec ESP32 WiFi LoRa v2 freezes

#1

Hello everyone,

I have a project based on the Heltec ESP32 WiFi LoRa v2, the goal is to acquire some commands from our remote server and sent commands to nodes via LoRa. Nodes are designed for being powered by a battery pack charged by a solar panel.
The nodes are giving us some trouble.

The big problem is that the nodes freeze, sometime after 10 hours, and sometimes after a week, it happens at random times.

Do you have any suggestions? External reset? I don’t know what to do next.

Thank you for your help

#2

What do you mean by freezing? Is the program stuck?

#3

Hi, @navi thanks for the response. ESP32 freezing means that nothing is in the serial monitor and nothing is on display and it starts working only after reset. I don’t think that its program is stuck because it’s happening not for all ESP32.

#4

Use the internal watchdog to see if this will happen.

#5

It is not freezing, it is sleeping for an long time - precisely the uptime subtracted from 2^16 seconds, and it is caused by the timer architecture involving two timers which don’t latch correctly. But there is a fix, and here it is.

  1. Always set the duty cycle to a multiple of 2 seconds. Any randomisation also a multiple of 2s.
  2. Wait for LoRaMacState != LORAMAC_IDLE before before LoRaWAN.sleep();

The bug is that Asr_Timer_Disable does not disarm the ISR. CySysTimerDisable stops the counters. CySysTimerDisableIsr would remove Timer1
from the interrupt controller’s active vector table — but it is not called.
Timer1’s ISR vector remains armed.

Because Timer1 has ClearOnMatch, when it reaches its match value it does not
stop — it resets its counter to zero and immediately begins counting toward the
next match.

The race condition that follows when g_timeout != 0:

  1. Timer1 reaches its match. Timer1IsrCallback fires.
  2. g_timeout != 0, so it calls Asr_SetTimeout(g_timeout).
  3. Stage 2 calls Asr_Timer_Disable() — Timer1 counters reset, ISR still armed.
  4. Stage 2 configures Timer0 for the short remainder and enables Timer0 only.
  5. Timer1, now reset and counting again with ISR still armed, reaches its
    match value a second time.
  6. Timer1IsrCallback fires again. This time g_timeout is 0. The callback sees zero and calls
    timerAlarmCallback() — before Timer0 has fired.
  7. The wakeup event is consumed and discarded. No new alarm is queued.

The device calls CySysPmDeepSleep() with no valid wakeup alarm armed.

I found out about this because there was a relationship between the deep sleep time and the elapsed time since the device was reset.

#6

It’s ESP32, not ASR.

Plus the thread, being 3 years old, relates to a product barely available anymore.

#7

All true. However, it is worth trying if the firmware is based on the same code base.

#8

The ASR functions are specific to ASR chipset - that’s the CubeCell range that uses things like the ASR6052.

So they’d have no bearing on the ESP32 at all. Except now Google thinks they do! :man_shrugging::wink:

#9

Yeah well I spent two weeks debugging this and found the reason to be the Heltec design, and I posted a fix.

Maybe it will help someone. Clearly not you.

#10

It’s not about it being a Heltec design at all - you are talking about code that sets up the internal configuration for a totally different microcontroller design from a totally different manufacturer.

It is like applying Swedish grammar to Arabic - not just different letters but a different direction.

There are other threads where the timer ticks, roll over, drift and more have been recently discussed for the CubeCell / ASR range that would benefit from your investigations.

#11

You sound like you already have the answer to why Heltecs seem to spuriously sleep for ~16hrs, please share.

#12

The point is that not all “Heltecs” are equal - there’s the old line of ASR boards and the new lines of ESP32 and nRF52. You commented for ASR in a thread about ESP32, which is likely to confuse people. We do not claim to have any knowledge about the ASR boards…

#13

There is no such thing as “Heltecs”.

For some unfathomable reason you think that all the boards that Heltec produce have the same engine.

Until you understand that they produce boards with different microcontroller designs - ESP32, STM32, nRF52840, ASR and so forth - and that they all have their own commands unique to each design’s peripheral - and that some of them use completely different instruction sets - you will be stuck in this loop forever.

You appear to have solved the ASR sleep issue. Please use that skill to understand how the peripherals (SPI, I2C, timers etc) in the MCU’s & hardware abstraction layers are built.

#14

This kind of response in a community is exactly what will make me stay away from constructively attempting to help others in the future.

#15

Is it because we’re trying to tell you that you are misunderstanding the issue and that have replied with a fix that’s not appropriate as politely as possible but we have run out of ways to try to explain it to you?

It doesn’t help to have an issue with the wrong answer unchallenged because it could cause someone problems trying to resolve their own project problems.

Look at the profiles - some of use have been helping lots of people, particularly with LoRaWAN which can be quite tricky. And almost always, when one of us gets called out, we read up on it and acknowledge we may have got it wrong.

So in some respects, if you can’t see that your solution is not applicable to ESP32, then perhaps it’s best you don’t try to help others if feedback on an incorrect solution doesn’t sit well with you.

#16

A better response might have been: Great that there seems to be a solution to the AB02S CubeCell freezing problem that many people have experienced. Thanks for that! You’ve posted the fix in the wrong thread, though, so please repost in a topical thread or create a new one.

1 Like
#17

Fair enough, feedback taken on board.