Anonymous | Login | Signup for a new account | 2021-01-18 20:22 UTC | ![]() |
Main | My View | View Issues | Roadmap | Repositories |
View Issue Details [ Jump to Notes ] | [ Print ] | ||||||||||
ID | Project | Category | View Status | Date Submitted | Last Update | ||||||
0000303 | Firmware | Scheduler (Inj/Ign) | public | 2011-10-18 12:14 | 2014-02-18 23:05 | ||||||
Reporter | Fred | ||||||||||
Assigned To | Fred | ||||||||||
Priority | immediate | Severity | crash | Reproducibility | always | ||||||
Status | assigned | Resolution | open | ||||||||
Platform | OS | OS Version | |||||||||
Product Version | 0.2.0-SNAPSHOT | ||||||||||
Target Version | 0.2.1 | Fixed in Version | |||||||||
Summary | 0000303: Add Sanity Checks For TCX Latencies | ||||||||||
Description | For each TC interrupt channel there should be a maximum latency over which sync is reset. Additionally, sync reset should clear all of the lastXYZ vars and turn off the IC interrupts. For this to be done, we need a mechanism to turn them back on again after some hysteresis time. The result of this being setup wrong is unstable outputs, and generally the code not doing anything except handling input pulses. For short pulses we need our output ON code to run quickly and successfully trigger the switch off, or, if too close, force it off immediately. Further protection should be added by way of the COP monitor to stop the entire CPU if main loop items are not being serviced often enough. It would be nice if we could come out of that knowing what happened when we came back up. To debug this I can add a last ISR run ID to the code that ALL interrupts must populate with a unique code. That way when there is a latency that is unexpected and undesired we can easily trace it by saving it from the ISR with the latency issue. if(latency too high){ save ID of latency cause; save latency value; to some GP var that gets logged reset sync; // including turning off IC ISRs }else{ store our ID in latency cause var; store latency for use in later calcs, if any; } The special log that I took exhibited curious injector channel behaviour in that injector channels are scheduled just after input pulses, using a fixed very marginal delay. Thus their code blocks (but not their on times) get deferred if there is latency on the input that fired them. The schedule minimum delay split in 0000127 must include this maximum latency figure too, otherwise latencies over the the base tolerance will screw up operation. | ||||||||||
Tags | No tags attached. | ||||||||||
FirmwareVersion | |||||||||||
Issue Type | Bug | ||||||||||
Risk of Breakage | very high | ||||||||||
Attached Files | |||||||||||
Copyright © 2000 - 2011 MantisBT Group |