Hi,
I described the issue a year ago here, https://vesc-project.com/node/4260 but unfortunately got no response. So I did a lot of testing during the last year to narrow the reason but with only little usable results. And I want to mention that I am very familiar with HW and SW- debugging.
I am using an Alien X8318 100KV – 42 pole on a bike. The wires between ESC and motor are about 40 cm long. Apart from some minor issues, everything went well. After a while, it started to get sporadic resets with immediate stoping motor (free wheeling bike). These resets got more frequent and end up to appear every few seconds. To narrow the source of the resets, I tried to change the control parameters, flashed newer SW, etc. And it sometime seemed that the resets disappeared, but after a while I always ended up in resets every few seconds. As there was always a possibility that it might be a hardware problem, I kept up with testing, trying 3 different VESCs and checking the wiring. Now, at least the fault appears quite reproducable. So the analysis is:
It makes no(meassurable) difference if the wires between the motor and ESC are mounted separated or parallel (influencing each other).
It happens in FOC and BLDC, with current, speed or duty-control at any ERPM. using a ADC or PPM- throttle Changing the control-parameters make no difference. I also tried different firmware, starting from 2.xx. Hoping that the bug was introduced with new features.
In about 50% of the resets I get no error message. If there are error messages I get ABS_OVERCURRENT and FAULT_CODE_BOOTING_FROM_WATCHDOG_RESET. Where in FOC-mode I get more watchdog-resets and less abs-current, tending to get more abs-current when lowering abs-max-current closer to max-motor-current(which means that the control is already lost). In BLDC-mode I mostly end up in ABS_OVERCURRENT. Sometimes the ABS_OVERCURRENT fault is truncated at around 3 parameters(does make sense if a reset without fault message occurs directly after the ABS_OVERCURRENT).
For frequent resets the motor current should be >20A (50A max.) but it does not really depend on it.
The (external) 3.3 V is very stable, so most likely it is no brown-out.
After quite a few resets the motor might not start any more, does only make noise, or I need to move the throttle several times to start the motor (ram-corruption?). Only a battery-reset helps. This points to a problem in pointer arithmetic rather than a runtime problem.
Changing the motor to a ‚normal‘ 12-pole motor, there are no resets at all.
As the motor runs for quite a few seconds in the same ‚static‘ mode ( flat paved road) before reseting, and as it runs perfect with 12 -pole motors my guess is that the ‚wind-up‘ of the SW happens somewhere in the back-reading of the EMF-signals from the motor. Before the path gets separated for FOC and BLDC.
After some internet-search I found on esk8 some comments about this issue, they got somehow solved, but with no real explanation ( apart from some with too much current for the setup)
The protocols of the parameters show no significant hint, there are timestamps missing for about 6 sec at the resets, and in rare cases it is possible that the timestamps get less frequent just before the resets, lacking a few ms. But the timestamps are not reset to 0.
Here you find the logs:
https://c.gmx.net/@325219879995048785/z6MXTR5ySPGiewSy6AhkcQ
Watch for the time stamps just before the resets, there are less entries in 75-100/BLDC! As for 6.6/FOC, this behavior before the resets is less (not?) present.
Protocol with BLDC-mode and 75100 on BLE, so the resets can be seen at the missing time stamps. ( BLDC -mode), FW6.02.
2023-06-03_10-54-39 frequent resets, less timestamps before reset
and 6.6 with FOC-mode. FW6.02
2023-06-23_18-28-04 Line 3687
2023-06-23_18-39-59 Line 4126, 14963, 15677
Hope that you find the reason for the watchdog resets, as the bike is not of big use with the actual behavior, and the resets are a permanent thread for fried HW, as already happened.
I am happy to support the debugging, but unfortunately I have only windows PCs, so it would be mainly testing. Compiling with Ubunu worked for a few years, but 2 years ago the script did not work any more.