0000303: Add Sanity Checks For TCX Latencies

View Issue Details [ Jump to Notes ]

[ Print ]

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 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.

Relationships