I do have watch in this state for many days but did not figure so far out how to find out what is exactly wrong with it. It is not frozen it just does not react to anything but it still works and saves power so I think the idle javascript loop still runs fine. Looks like it is in some high level logical 'lock' or bad state. When it 'froze' gadgetbridge was still connected over BLE and stayed being connected without reporting any error. I disconnected it like hour after it froze and it disconnected just fine, again without reporting that anything is wrong with the connection, however it just could not reconnect later. After one day the screen went blank (may be some screen blanking code?).
The trouble with using SWD debugger is that with bluetooth stack enabled you cannot stop the CPU and then resume because BLE stack will immediately crash due to strict timing needed. So I have one shot and then need to reboot the watch. Also when Espruino works and is in idle loop/sleep and I halt the CPU it is in some interrrupt context and I don't see regular stacktrace where I could see how C function calls are nested and could examine local C variables on different levels. When I keep it running I can just read memory like global C variables but don't see what it is doing. I have few ideas - I need some live profiler that could sample running code (CPU registers and stack/RAM) without stopping it, should be doable somehow but I did not figure out details how to do it with openocd/gdb. Also I can make custom firmware with some extra logging and extra debug code and wait with this for next freeze. I am planning to implement javascript console over SWD (another object of javascript Serial type like Bluetooth) and then I hope I can switch console input/output at runtime it this 'frozen' state. Maybe I could still run some javascript in this state.
Espruino is a JavaScript interpreter for low-power Microcontrollers. This site is both a support community for Espruino and a place to share what you are working on.
I do have watch in this state for many days but did not figure so far out how to find out what is exactly wrong with it. It is not frozen it just does not react to anything but it still works and saves power so I think the idle javascript loop still runs fine. Looks like it is in some high level logical 'lock' or bad state. When it 'froze' gadgetbridge was still connected over BLE and stayed being connected without reporting any error. I disconnected it like hour after it froze and it disconnected just fine, again without reporting that anything is wrong with the connection, however it just could not reconnect later. After one day the screen went blank (may be some screen blanking code?).
The trouble with using SWD debugger is that with bluetooth stack enabled you cannot stop the CPU and then resume because BLE stack will immediately crash due to strict timing needed. So I have one shot and then need to reboot the watch. Also when Espruino works and is in idle loop/sleep and I halt the CPU it is in some interrrupt context and I don't see regular stacktrace where I could see how C function calls are nested and could examine local C variables on different levels. When I keep it running I can just read memory like global C variables but don't see what it is doing. I have few ideas - I need some live profiler that could sample running code (CPU registers and stack/RAM) without stopping it, should be doable somehow but I did not figure out details how to do it with openocd/gdb. Also I can make custom firmware with some extra logging and extra debug code and wait with this for next freeze. I am planning to implement javascript console over SWD (another object of javascript
Serial
type likeBluetooth
) and then I hope I can switch console input/output at runtime it this 'frozen' state. Maybe I could still run some javascript in this state.