I am building a programmable car ignition system based around a microcontroller. I would like to ensure that the system reboots itself should the micro freeze, rather than stop the engine in the fast lane. The internal watch dog timer (WDT) won't work if the micro locks up. My thoughts are to monitor the micro output pin that drives the ignition coil via an IGBT using a missing /stopped pulse detector to momentarily disconnect and reapply the power to unfreeze the microcontroller. As this output is only available once the engine is running I need to work out a way to inhibit this rebooting while starting the engine. That is the part that is giving me a headache as I'm trying to keep this as simple as possible and definitely only in hardware.

Grateful for any ideas

David

 

It would be very simple to configure a 555 timer as a watchdog and use the ignition circuit to hold the timer reset pin 4 low.

 

Thanks. I was thinking of using a 555 in a retriggerable monostable mode so that it kept the power on as long as the micro was sending pulses to the coil driver but turned it off for a short period if there was no output. I need to be able to keep it powered while the ignition switch is turned on but the engine isn't running. So there are two different scenarios where the micro output is off but only one requiring the powers to be retained - before the starter is engaged. One option is to use another 555 to provide for a period of say 30 seconds to retain the power before the engine runs. Not very neat but I guess it would work.

David

 

Could you pick up voltage from the ignition switch when it is turned to the 'start' position to enable the ignition. Once the key is returned to the 'on' position the engine is running and the watchdog can be enabled.

 

The internal watch dog timer (WDT) won't work if the micro locks up.

Which micro are you using? The internal WDTs with which I am familiar (PICs mostly) use a dedicated RC timer and optional prescaler that is independent of the rest of the CPU and work even if the CPU oscillator fails. Some have backup system clock oscillators to take over if the main oscillator fails due to a broken crystal etc. I'd be comfortable using these if available. Add an external fallback if you like but consider that it is another point of failure. It would be a shame if the CPU was OK but the external watchdog failed and crowbarred the system.

However the WDT is implemented, how you pet the dog is important. I would be reluctant to pet the dog as a side-effect like you are proposing. I don't know your software but that can be problematic if your code gets hung in a loop that toggles the IO, your WDT function will fail. Same problem if the WDT reset is in a timer interrupt routine.

My preference is to clear the dog in exactly one place in the task scheduler or top of a superloop if that's what you have. Before petting the dog, you can run some on-the-fly diagnostics to ensure that things like IO configuration, interrupt enables, peripheral setups, stack pointer at the expected place, no math overflows or ADC out of range errors etc. occurred in the task or loop pass. Then pet the dog and do the next thing. If you DO find something out of place you are at a natural point to re-initialize and continue, flag errors or go to an orderly shutdown/limp mode. This method will catch expected and unexpected errors.

If you decide to use an external watchdog, consider a real system supervisor chip. MIC1232 is an example but there others from ST, Maxim and such. These don't require external components like the 555, aren't as sensitive to transients and don't have the 555 issue of DC coupled inputs. I'd avoid that myself.

In any case, sounds like a cool project.
Good luck and welcome to AAC!

 

Frankly, if I had an ignition system that could fail in a non-recoverable mode and was worried "about it happening in the fast lane," I would consider two, independent ignition systems.

I had a 2000 Honda Accord, and when its alternator went bad (no charge panel light), the battery failed while in the fast lane on an Interstate in Cleveland (Harvard and I-77). All Hades broke out on the panel. No speedometer, etc. Shift to neutral and coasted to the road side on the right. I walked quite a ways before finding a business that would let be make a local call. That broke my resistance to having a cell phone.

 

Use the watchdog on your microcontroller. That's why it is there. See:
https://www.allaboutcircuits.com/technical-articles/watchdog-timers-microcontroller-timers/
If something happens to the microcontroller which also kills the watchdog, an external reset probably will not recover normal operation.

 

Thanks for all the suggestions. The PIC I am using is a 16F88 and the program is one that was published in a magazine over ten years ago that works well enough. The WDT is turned off but I don't think I am skilled enough currently to re-write the relevant parts of the program although that could be my longer term aim. My modifications at this stage are focused on converting the ignition to do away with the distributor, providing better isolation of the trigger inputs through opto-isolators and cleaning up the power feed and protection. I've not experienced lock up issues so far, but am concerned that there is no fall back. I am aware that the 555 does have its issues so will have a look at the MIC1232 which is available locally and is designed for automotive use and provides a number of potential benefits.

I have considered taking the feed from the ignition switch that is live during start-up and that may prove to be the easiest and most reliable solution to that part of the problem. At present I can switch back to conventional ignition on the fly as a safety measure but once I do away with the distributor that isn't a viable option.

 

If your watchdog trips, not a huge problem. The engine will stumble for the time needed for the MCU to restart and resume which should not take long. You can even write firmware that barely skips a beat.

Worst case is if the MCU hangs when an IGBT is on, it can overcurrent in even 10msec and risk damaging the IGBT. Coil-on-plug modules usually have smart protection for that.
A hard aspect is keeping the MCU running during cranking when system voltage can go really low, even 4V swings. Car ECU's have buck/boost SMPS.

Silicon Chip magazine has done a few car ignition projects like Nov. 2012 but you have to purchase the issue and they don't give out source-code, only .hex files for the PIC.

 

If your watchdog trips, not a huge problem. The engine will stumble for the time needed for the MCU to restart and resume which should not take long. You can even write firmware that barely skips a beat.

Worst case is if the MCU hangs when an IGBT is on, it can overcurrent in even 10msec and risk damaging the IGBT. Coil-on-plug modules usually have smart protection for that.
A hard aspect is keeping the MCU running during cranking when system voltage can go really low, even 4V swings. Car ECU's have buck/boost SMPS.

Silicon Chip magazine has done a few car ignition projects like Nov. 2012 but you have to purchase the issue and they don't give out source-code, only .hex files for the PIC.

At present I am using an ignition coil with a fairly high primary resistance, around 3 ohms, so the IGBT and coil are not at much risk. However, when I move on to the system without the distributor for the HT this will be an issue with the double ended coil pack with primary resistance of <1 ohm, so I have a current sensing isolating circuit on the breadboard that seems to work. I've tried measuring the cold cranking voltage and so far not gone below about 8volts with the starter turning after the initial dip as it engages. The input capacitor before the voltage regulator is fairly large but maybe I need to test this further?
I see Silicon Chip magazine is now making the .asm files available for some of the older projects - I do have copies of the articles as well.

 

There would be a series input diode to prevent the capacitor from discharging back into the car, instead of supplying power, during dips in system voltage. In winter, you get pretty low cranking voltages I think the SAE standard is ECU operation at 4V.

 

Thanks, I will need to think about using a buck boost converter to maintain the voltage under extreme cold cranking conditions. I have avoided SMPS options at this stage as I am trying to limit issues due to switching noise but once everything is working properly that is worth checking out.

 

We have an electric scooter which uses a 2nd microcontroller as a fail safe monitor to stop the scooter if the main micro locks up. It should be easy to configure it to reboot the main micro instead.

 

That’s an interesting concept, but maybe too many additional components. I’ll have a think about that as it could handle the start-up issue as well as the lock-up. Thanks.

 

A little 8 pin PIC which detects if the joystick is released and if voltage is still on the motor driver FETs, it releases the main relay supplying power to the board. No additional power filtering and no pull ups or pull downs on the ports were necessary.

 

That sounds like a simple option, thanks again for the info.