Mantis Bug Tracker

View Issue Details Jump to Notes ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0000303FirmwareScheduler (Inj/Ign)public2011-10-18 12:142014-02-18 23:05
ReporterFred 
Assigned ToFred 
PriorityimmediateSeveritycrashReproducibilityalways
StatusassignedResolutionopen 
PlatformOSOS Version
Product Version0.2.0-SNAPSHOT 
Target Version0.2.1Fixed in Version 
Summary0000303: Add Sanity Checks For TCX Latencies
DescriptionFor 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.
TagsNo tags attached.
FirmwareVersion
Issue TypeBug
Risk of Breakagevery high
Attached Files

- Relationships

-  Notes
There are no notes attached to this issue.


Copyright © 2000 - 2011 MantisBT Group
Powered by Mantis Bugtracker