assert failed + reboot on Remote command #896
-
I am running Paxcounter on a If I send a Remote command to deactivate the Wifi Scanner following error occurs:
Same happens with remote command to deactivate Bluetooth. Overview: Not working |
Beta Was this translation helpful? Give feedback.
Replies: 4 comments 17 replies
-
The #define BLECOUNTER / WIFICOUNTER statements in paxcounter.conf control wether the code blocks for wifi/ble are to be processed during build. They don't control the runtime default settings which can be altered by rcommands. If you change these #defines remember to clear the default settings from NVRAM from previous build, before flashing the new build:
|
Beta Was this translation helpful? Give feedback.
-
because espressif32@5.2.0 did not build. What's the problem here, can you provide error log? |
Beta Was this translation helpful? Give feedback.
-
The issue still exist for me even with the new release (3.4.3). The logs are here. Board Steps:
Workaround (logs):
This also happens if I want to deactivate the BLE Scanner (when a sleep cycle is set)
Can anyone confirm this issue? I have tried multiple Heltec Boards. |
Beta Was this translation helpful? Give feedback.
-
I got this. It's an RTOS timer in libpax lib which is stopped, while it does not exist. This results to a crash. The root cause is a mix of sleep flow control in paxcounter, and behavior of libpax function The issue occurs, when remote commands arrive while the device is already in going to sleep flow control. At this time A quick fix is to make
A probably more straight forward way would be to rework the flow control of enter_deepsleep(). This way also would solve the behaviour of "one more sendcycle round before going to sleep" after a sleep cycle command was send to the device. I openend issue and PR in libpax repo. |
Beta Was this translation helpful? Give feedback.
I got this. It's an RTOS timer in libpax lib which is stopped, while it does not exist. This results to a crash.
The root cause is a mix of sleep flow control in paxcounter, and behavior of libpax function
libpax_counter_stop()
, and, thus, can be fixed on two ways: Either in libpax code, or in paxcounter code.The issue occurs, when remote commands arrive while the device is already in going to sleep flow control. At this time
libpax_counter_stop()
was already called byenter_deepsleep()
, to stop libpax enqueuing payload which would lead to an endless waiting loop inenter_deepsleep()
. So far not a problem. But when at this time a remote command arrives, which also callslibpax_counter_st…