Closed p-h-a-i-l closed 5 years ago
If DMA is still running, we can watchdog in there....
I am working with machine protocol with #39 . Today I had one crash upon sending speed command. Board powered off, I turned it back on and checked temp with ASCII.... It was 140C.... Inspected with thermometer and it was only 35.
Did you hear the shutdown melody? When I speak of crashing, I'm thinking of undefined behaviour, endless loops where you have to pull the battery or power off without going through the proper poweroff() function.
Yes, I heard shutdown melody. I experienced crashing with original repo, when hoverboard could not handle too fast communication.
Ok, when you heard the melody, it's a different Issue.
I also noticed the other day that the temp was reporting high at boot then falling. In my case falling from ~50C. I thought it was too high for just the 1A load tests I was doing.... so maybe we screwed the temp ADC reading?
stop hijacking my bug ;)
use https://github.com/bipropellant/bipropellant-hoverboard-firmware/issues/52
I can confirm crashes, at least when using speed PID control on UART2. Works for 1-2 minutes and that's it.
Are you sure it is a crash? Does the power button work when you experience a crash like that?
I haven't seen these crashes as I mentioned when opening this issue since the switch to sinusoidal control was done.
Hm, weird. It just stopped happening since today - now everything runs just fine. Power button worked, but serial connection was broken.
Ok, then it might have been a different kind of crash, but my first guess is EMI problems..
I'll close this issue, haven't seen these crashes anymore and every other report was not related.
I felt like I had to leave a warning somewhere ;)
When using the machine protocol with USART2 and USART3, the main routine crashes pretty often for me. That's also the reason why I'm not actively using this fork. In my own branch only minimal parts of this fork are implemented, this is running stable. Also a watchdog is running which at leasts stops the motors since the bldc interrupts keep on firing happily :) My goal is to merge both back together, but it looks like we're short on timers. Maybe in the final product you have to decide between function vs. watchdog.
While merging electricalmeasurements, pid and Flash functionality, instability came back too. Need to look further into the root cause, but wanted to leave this here as warning.
Neither timeouts nor a watchdog is implemented right now in bipropellant-hoverboard-firmware.