|Anonymous | Login | Signup for a new account||2020-02-29 12:26 UTC|
|Main | My View | View Issues | Roadmap | Repositories|
|View Issue Details|
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0000213||Firmware||General Features||public||2011-07-18 07:04||2014-02-18 23:47|
|Target Version||0.2.0||Fixed in Version||0.2.0|
|Summary||0000213: Better And More Robust Handling Of PLL|
|Description||Attempt to ensure that the EMS can still function in a sort of low performance limp mode should PLL be lost, and also ensure that it tries to regain PLL. I'm unsure what currently happens when PLL is lost, but probably bad things, such as nothing.|
|Tags||No tags attached.|
|Risk of Breakage||medium|
I've spent all day working on this and related stuff. Much of it reading the fucking manual like a good boy.
It looks like loss of PLL should result in normal low speed operation. Likewise loss of main clock should fall back to self clock mode.
Currently it appears as if that doesn't happen because the main loop fails to service the COP if configured when the main clock is glitched. It therefore must be:
Stuck executing an ISR repeatedly
Stuck in bad code in the SM due to bad vector redirection.
Tested today with a modified FW build.
More results here: http://forum.diyefi.org/viewtopic.php?f=8&p=34160#p34160 [^]
Summary: PLL successfully re-enables itself every time without issue. Comms and other time based things are likely corrupted/wrong in the mean time.
I should enable and catch the interrupt and force a sync loss, then disable the timer inputs/outputs until it is brought back to life, then restore normal operation.
The main clock needs to be handled too, but that's a separate issue.
|Update target version.|
|Available in hash 3959ba8 from dev branch. Please code review and close if happy, and if you see that Andy is happy running it on his car.|
|Closing as this seems to function as designed.|
|Copyright © 2000 - 2011 MantisBT Group|