Searching \ for 'CCP Modules from HELL!!!' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page:
Search entire site for: 'CCP Modules from HELL!!!'.

Truncated match.
PICList Thread
'CCP Modules from HELL!!!'
1998\07\13@173345 by craiglee

A week ago I posted a message about how happy I was to get
my ignition system working.

Well after some testing and pulling out of hair, and toenail biting,
I am stuck.

The CCP modules seem to be missing or misfiring.  I moved my
coil outputs to PORTA from PORTB as I thought that since my
flywheel sense was on RB0, it could be causing some problems.
Doing this, reduced the problems.

So I changed the design to use a tooth count to do the dwell, as this
appeared to be where I was having the most problems.  However, this
proved unreliable.

So I changed the design again to load the CCP2 module with the dwell
for the next cylinder when CCP1(firing) interrupted.  This too was

Each method works reliably for the majority of frequencies.  The problem
at various random frequencies over my range of 250 to 6000 rpm.

I see two notes in the data books that bother me:

1) on page 14-4 of DS31014A:  Timer1 must be running in timer mode or
    syncronized counter mode for the CCP module to use the capture feature.
In asynchronous counter
    mode, the capture operation might not work.

I am using the CCP modules in compare mode only using the internal
oscillator.  I've tried using
an external oscillator, changing my serial communication speed (and turning
it off), shorting pins
10 and 11 ('73A).  Still the problem exists, at the same input frequency on

2)  on page 14-13 of DS31014A: The example(14-4) on compare initialization
does not use the interrupt.
     Does this imply that the software interrupts for the CCP modules do
not work?

Anyone?  I am very concerned as it puts into doubt the reliability of this


1998\07\14@193747 by Tony Nixon

picon face
Does it make any difference if you are testing your system in a vehicle
or just on a bench?

>From experience, the PIC is very sensitive to automotive 'hash'. Just
having an unshielded wire connected to the PIC that runs any where near
a coil lead, for example, will make the PIC run erratic >>>at times<<<.
These bugs may even be RPM dependant.

It can be a very frustrating and time consuming experience trying to
find the causes of missfiring etc with micro based systems.

The main, and obvious, thing to do, is protect the PIC from all nasties
that come from the vehicle wiring system, including EMI.

I think Harris semiconductor has some info in this area.




PicNPoke Multimedia 16F84 Beginners PIC Tools.

1998\07\14@212843 by Mike Keitz

picon face
On Wed, 15 Jul 1998 09:36:01 +1000 Tony Nixon
<.....tony.nixonKILLspamspam@spam@ENG.MONASH.EDU.AU> writes:
>Does it make any difference if you are testing your system in a
>or just on a bench?

Definitely test it on a bench first.  Simulate the necessary inputs.  I
think the main input was pulses from a crank sensor, which could be
generated from another PIC running a simple loop.  Clock that PIC with an
RC oscillator and vary R to change the simulated RPM.  The simulator PIC
could also put out some other signals to synchronize scopes, etc.

If the control PIC works correctly with simulated inputs, the software is
not too bad.  The next step would be to connect the coils and spark plugs
the same way they would be in the vehicle.  Note that spark plugs firing
in atmospheric air need much less voltage than in normal operation.  So
set the test plugs up with a much wider gap than usual.

It's likely that all that sparking is going to cause trouble.  But now
everything is on the bench so you can easily try some countermeasures.
If it still seems to be working OK, the problems unique to the vehicle
would be the crank sensor and the power/ground arrangement.  You might
try the system in the vehicle only use a seperate battery to get clean
power.  Should that work OK, obviously better power filtering and
distibution is needed.  If it's that the crank sensor doesn't put out a
clean signal, the simulator could be changed to make a similar signal.
Countermeasures for the dirty crank sensor signal could be tried on the
bench then.

You don't need to buy Internet access to use free Internet e-mail.
Get completely free e-mail from Juno at
Or call Juno at (800) 654-JUNO [654-5866]

1998\07\15@023219 by Tony Nixon

picon face
Mike Keitz wrote:

> If the control PIC works correctly with simulated inputs, the software is
> not too bad.  The next step would be to connect the coils and spark plugs
> the same way they would be in the vehicle.  Note that spark plugs firing
> in atmospheric air need much less voltage than in normal operation.  So
> set the test plugs up with a much wider gap than usual.

Testing the PIC any where near spark plugs in the open will invite
trouble. The PIC will complain terribly. Try it out and see. I learnt
this the hard way:-)

Multimedia 16F84 Beginners PIC Tools.

PicNPoke, PicNPlay, PicNPlan, PicNPrep, PicNPost,
PicNPort, PicNQuiz, DT Type Saver and HexPic.

1998\07\15@105531 by craiglee

Well I built an engine simulator with an '84 and a rotary encoder for
adjusting the 'RPM' because I had doubts about my input signal.

So the problems I was facing was not due to any noise interference
unless it was from spurious transmission from my breadboards.

The issue still exists, even when I remove the CCP modules completely
and adopt a new method using TMR0 and TMR1 and the INT for my sensor
input.( changing to RBIF didn't fix it either)

I've changed my outputs to PORTA from PORTB, I've changed the XTAL freq,
I've changed my prescale(different count, test math), I've shut the serial
off(no serial divides), I've done everything, and the same input frequencies
cause the problem(it's not the input signal itself) (power supply is clean)

So I went back to revision 1.6 of my code, and removed CCP2 only, this was
supposed to ensure a 4ms dwell on each cylinder, but I removed it and set
in the CCP1 interrupt(the fire interrupt) to dwell the next cylinder
immediately.  Not optimum, but you know what, it worked!  I still had a
at 4484(223) and 5319(188), but by turning off CCPIE and turning it back on
after setting the module, seemed to fix these (odd, I think so, as this was
on interrupt)

Upon further analysis, revision 1.6 does not suffer the same fate whereby
the missing tooth detection algorythm(which is the same throughout) seems
to 'twitch' at certain frequencies.  Very odd indeed!!!

So the problem may not be the CCP modules themselves, but part of a larger
problem, which I don't have time to isolate at this time.

Here's some approx. periods if any math wizards want to tackle it for
(in microseconds)
666(here's our first clue)
634 532 516 446 378 361-359 328 310 207 192 173 157 156 151

Anywho, here is an update, as it's clear the engine isn't causing the
..... yet.


{Original Message removed}

1998\07\15@122130 by Timothy D. Gray

Not if everything is properly shielded, ferrite beads on wires entering
and exiting the RF tight box.

{Quote hidden}

1998\07\15@124307 by ceddy

Long shot, Craig..

I used to use a piece of code in my main loop that updates the TRIS registers
over and over again.  The theory is that if a TRIS register gets lost, it will
then be re-established.  The problem that I found was that doing this caused
false and wrong states on the I/O pins.  Even though I was writing the same
darned direction data to the TRIS!  I even had this problem cause an analog
input pin to turn to an output ever so briefly (repeatedly), convincing the peak
to peak software that there was a healthy AC component on the line.  All of the
cases that I uncovered were cured imediately by commenting out the TRIS writes
(do it only once at init).

This may have something to do with your troubles.  A motor controller with PWM
that I built was one of the projects that I had trouble with.  This only applies
if you are writing TRIS over and over.

Good Luck.
Chris Eddy, PE
Pioneer Microsystems, Inc.

Craig Lee wrote:

> Well I built an engine simulator with an '84 and a rotary encoder for
> adjusting the 'RPM' because I had doubts about my input signal.

1998\07\15@163939 by Thomas McGahee

Circuits that work just beautifully on the test bench will often bomb
out under real world conditions. The environment encountered within
the innards of an automobile can be quite overwhelming from the
point of view of a PIC.

The power supply voltage itself is rife with all sorts of noise. The
automobile battery is a low impedance source, but it is connected
to an ignition system and other nasty things that generate spikes
and all manner of RF hash (noise).

When designing microcontroller circuits for use in automotive
applications, here are *some* of the things I do:

Enclose the entire circuit board assembly in a sealed metal container.
I usually use extruded aluminum casings with attached metal plates
secured by self-stripping screws or tapped to receive standard
machine screws. Plastic cases are a no-no, although I know some people
who use plastic that has been sprayed with conductive paint.

The case now acts as a Faraday cage and prevents unwanted RF from
getting to the main PC board assembly. To this end, the case is
supplied with a section of copper braid or flat copper strip that
is firmly attached to the case. The other end of the braid or strip
is attached to the car chassis. The braid or strip has a large
ring terminal and is secured using an existing screw or via a
heavy duty self-tapping hex screw and a washer. This connection is
used solely for its RF protection, and is *NOT* used as a power

RF will try to get in to the enclosed PC board via any available
outside-world connection it can find.

The POWER LEADS that go to +12 and Ground can themselves act as
an RF antenna system, and any opening through which ANY lead is
brought can introduce noise to the system. For this reason it is
a good idea to include an LC type hash suppression filter
directly in line with the power leads. Keep power leads as short
and as thick as you can. You can use shielded wires to help
cut down on RF and noise. The appropriate ground point for
such shielding is the metal case. The external power ground should
first go the the PC board, and then the PC board ground can be
connected to the inside of the metal case.

The +12 from the battery should be RF filtered before being applied
to the PC board. (A PI style filter works well). The +12 then needs to
be reduced to +5v for the PIC and other circuitry. The INPUT of the
regulator should have at least a 100 ufd 25v electrolytic in parallel
with a 10 ufd 25v tantulam capacitor, and a .1 ufd ceramic capacitor.
The electrolytic will provide major filtering of the low frequency
component, while the tantulum provides faster response for the
frequency components that go up to a few Khz, and the ceramic cap
handles the higher frequency noise.

The output of the +5v regulator should include at least a 10 ufd
tantulum and a .1 ufd ceramic cap. This will supress the tendency of the
regulator itself to oscillate, among other things.

All wiring to and from the outside world are possible sources of
electrical noise getting into the system. Using shielded wire and
twisted shielded wire helps significantly, but any wire going near the
ignition system is going to be subject to really nasty noise. You can
minimize the noise by adding a high frequency trap (filter) at the point
where the wire connects to the PC board. Use WIDE ground traces
whenever possible, and use a ground plane on the PC board if you can.
If you can't, then consider putting an insulated external ground 'plane'
as close to the bottom of the PC board as possible. This gives RF a
safe place to go.

For those REALLY nasty cases of RF, consider using optoisolators, or even
fiber optics to get the digital signals into and out of the system

"Bench" testing is done with an array of noise producing circuits
purposefully creating a harsh environment. Hey, I even have a
complete ignition system running. If it survives my bench, it
usually survives the real world.

Once I have a system working 100% to my satisfaction, I often
encapsulate the system with an epoxy resin or tar-like encapsulant.
This seals out moisture.

Hope this helps.
Fr. Tom McGahee

{Quote hidden}

More... (looser matching)
- Last day of these posts
- In 1998 , 1999 only
- Today
- New search...