I have a long term stable GPS lap timer project based on a 128a1 processor that has been solid for 2 or 3 years now, used about 30 times a year to do predictive lap timing in a race car.
From the beginning of the season I experienced some issues with the lcd displaying corrupt characters. I thought I had nailed it when I found the engine builder had put non-resistive spark plugs in during the winter rebuild (this was also affecting the in car video). I change the plugs and the video was fine but I still got display issues.
I then pulled apart the 8 way binder 712 lcd connector and remade it. I thought I had found the issue there as the gnd wire appeared to be detached, but maybe it just became detached as I took it to bits.
I then tried reducing the serial speed from 115200 to 57600 to the lcd but it made little or no difference.
The problem is only seen in the race car when the engine is working under load, static revving of the engine does not produce the effect. Load on the engine will increase the strength of the spark as I understand it.
I ran a test where I left it running even though the display was corrupt and in the summary file it produces I noticed it was reporting (never seen before) checksum errors on the incoming nmea record. So now I have corruption in 2 separate com channels it seems.
I have a new unused cpu on the Sparkfun break out board (now annoyingly discontinued) but replacing it is non-trivial, and I wonder if there are other sensible steps to take first. Could the crystal be running out of spec, there is very little other compentry really.
The problem is either air-borne interference related or vibration related from tests to date but this might not be conclusive as testing in the right conditions is hard to achieve.
Something has changed somewhere for sure.
Any ideas appreciated
Strange uart behaviour on previously stable project
I think its holiday time for for Don - we all got to have one some time.
I started ensuring I knew where all the wires went before I started the cpu swap. in doing so, I discover one of the caps on the crystal is mostly adrift from the crystal side, probably vibrating on/off at times.
Is this a likely culprit to my uart issues or do I press ahead and swap the cpu ?
I started ensuring I knew where all the wires went before I started the cpu swap. in doing so, I discover one of the caps on the crystal is mostly adrift from the crystal side, probably vibrating on/off at times.
Is this a likely culprit to my uart issues or do I press ahead and swap the cpu ?
I would think the first step is to try to determine if the interference is EMI, (RF), entering the wiring harnesses, noise on the power supply bus, noise on other input signals, the clock frequency, or of other etiology.
Regarding the cap on the Xtal, If the system was stable and error free for several years, and soldering the cap down solves the problem, then call it a day and move on.
Otherwise just run a simple test program that outputs the uC's clock on a I/O pin, and look at it with an O'scope of a frequency meter. Simple check it with and without the cap soldered down and see the difference. I don't know how big the difference will be. If the clock is within 2% of the expected baud rate, then the USART would be expected to work fine, from this perspective. (Could still have software issues, etc.)
Vehicles are known for having very noisy electrical buses and having Load Dump issues.
Is the project running from the vehicle's power supply?
If so, then are you using a heavily filtered, and load dump protected, power supply?
Do you have other inputs attached to the vehicle and the uC's board, (e.g. voltage monitor, RPM signal, anything tied to the vehicle's power supply in any manner)? If so, each of those connections need to be filtered and over voltage protected for reliable operations within a vehicle.
Are your off-board wiring connects within a shielded cable?
One can argue about how to ground a shield, but for starters I would have all such wires within a shielded cable, and connect the shield at only the PCB end of the shield.
"Worse when running "under load"."
They implies to me that it is worse when running under non-idle RPM's.
At what RPM does the vehicle's alternator kick in and start charging the battery and powering the bus, instead of the battery powering things?
Could it be the alternator is generating (more) noise when under load?
Lots of items to sort out.
JC
Edit: Swapping the uC would be very low on my list of items to check / test.
Regarding the cap on the Xtal, If the system was stable and error free for several years, and soldering the cap down solves the problem, then call it a day and move on.
Otherwise just run a simple test program that outputs the uC's clock on a I/O pin, and look at it with an O'scope of a frequency meter. Simple check it with and without the cap soldered down and see the difference. I don't know how big the difference will be. If the clock is within 2% of the expected baud rate, then the USART would be expected to work fine, from this perspective. (Could still have software issues, etc.)
Vehicles are known for having very noisy electrical buses and having Load Dump issues.
Is the project running from the vehicle's power supply?
If so, then are you using a heavily filtered, and load dump protected, power supply?
Do you have other inputs attached to the vehicle and the uC's board, (e.g. voltage monitor, RPM signal, anything tied to the vehicle's power supply in any manner)? If so, each of those connections need to be filtered and over voltage protected for reliable operations within a vehicle.
Are your off-board wiring connects within a shielded cable?
One can argue about how to ground a shield, but for starters I would have all such wires within a shielded cable, and connect the shield at only the PCB end of the shield.
"Worse when running "under load"."
They implies to me that it is worse when running under non-idle RPM's.
At what RPM does the vehicle's alternator kick in and start charging the battery and powering the bus, instead of the battery powering things?
Could it be the alternator is generating (more) noise when under load?
Lots of items to sort out.
JC
Edit: Swapping the uC would be very low on my list of items to check / test.
thanks for the considered reply. To cover a few points quickly:-
the project is self contained and self powered, no connection to the car at all.
the vehicle doesn't have an alternator, total loss electrical system.
> They implies to me that it is worse when running under non-idle RPM's.
its not just non-idle, its under under heavy load, like acceleration. Just revving it up does not produce the problem. So its not reproducible easily is the other issue. Its a track only car and my drive isn't bog enough for runs under load. Scoping signals is therefore not really possible.
It all used to work so am looking for new issues. I have for now fixed the caps issue and next race is last weekend in Aug so i'll report back.
The project is housed in a metal case, would binding this to vehicle ground or even project battery ground be worthwhile. it never was but it feels as if it might be an improvement, or will then rfi shield by the case be transmitted into the project psu ? i.e. might make things worse.
the project is self contained and self powered, no connection to the car at all.
the vehicle doesn't have an alternator, total loss electrical system.
> They implies to me that it is worse when running under non-idle RPM's.
its not just non-idle, its under under heavy load, like acceleration. Just revving it up does not produce the problem. So its not reproducible easily is the other issue. Its a track only car and my drive isn't bog enough for runs under load. Scoping signals is therefore not really possible.
It all used to work so am looking for new issues. I have for now fixed the caps issue and next race is last weekend in Aug so i'll report back.
The project is housed in a metal case, would binding this to vehicle ground or even project battery ground be worthwhile. it never was but it feels as if it might be an improvement, or will then rfi shield by the case be transmitted into the project psu ? i.e. might make things worse.
Sorry for the delay in responding - been on holiday somewhere with zero coverage !
Only sensor inputs at the moment are gps, there are other optional input bit all have been disconnected to eliminate from the issue.
The caps on the crystal are close to the pins if that's what you are asking, like 5mm or so really, and that was where the dodgy solder joint lay.
Opportunity to test 1 week tomorrow. If that fails i'll swap the cpu.
Only sensor inputs at the moment are gps, there are other optional input bit all have been disconnected to eliminate from the issue.
The caps on the crystal are close to the pins if that's what you are asking, like 5mm or so really, and that was where the dodgy solder joint lay.
Opportunity to test 1 week tomorrow. If that fails i'll swap the cpu.
Rosariote was talking about By-pass caps.
The issue is that the M128 has two Vcc and an AVcc pin.
ALL of them need to be connected to Vcc.
All three of the Grounds need to be connected to Ground.
Both of the Vcc and the AVcc pins should have a By-Pass cap, typically a 0.1 uF cap placed as close to the micro's pins as possible.
If you were using the ADC or the AC, then it would make sense to connect AVcc to Vcc through an LC filter, (not an RC filter), otherwise just tie it to Vcc and add a By-Pass cap to Ground.
You additionally might want to add a 4.7K or 10K pull up resistor to the Reset pin, with another 0.1 uF cap to Ground. Than will improve the noise immunity of the Reset circuitry, which has a weak, internal, pull up resistor.
Adding that might give some programmers a hard time programming the uC.
(True Atmel programmers shouldn't have a problem with 10K/0.1uF on the Reset pin.)
How/were is the GPS with respect to the uC?
If it is outside the box, distant to the uC, is it connected via a shield cable?
JC
The issue is that the M128 has two Vcc and an AVcc pin.
ALL of them need to be connected to Vcc.
All three of the Grounds need to be connected to Ground.
Both of the Vcc and the AVcc pins should have a By-Pass cap, typically a 0.1 uF cap placed as close to the micro's pins as possible.
If you were using the ADC or the AC, then it would make sense to connect AVcc to Vcc through an LC filter, (not an RC filter), otherwise just tie it to Vcc and add a By-Pass cap to Ground.
You additionally might want to add a 4.7K or 10K pull up resistor to the Reset pin, with another 0.1 uF cap to Ground. Than will improve the noise immunity of the Reset circuitry, which has a weak, internal, pull up resistor.
Adding that might give some programmers a hard time programming the uC.
(True Atmel programmers shouldn't have a problem with 10K/0.1uF on the Reset pin.)
How/were is the GPS with respect to the uC?
If it is outside the box, distant to the uC, is it connected via a shield cable?
JC
all sound like very sensible suggestions, but I keep coming back to the fact it has worked for nearly 3 years without these issues, so amending the design, whilst to recommended standards would not appear to be indicated at this stage. I'd like to get back to a stable known point before making modifications although most sound like they should be planned in anyway.
We'll see how the fix performs this weekend.
We'll see how the fix performs this weekend.
Strange uart behaviour on previously stable project
Putting the 0.1 if caps on power pins should be done regardless if not already in your circuit.
Have you changed the battery brand or type you are using?
On Aug 24, 2015, at 6:12 AM, ZBasic <zbasic.forum@zbasic.net (zbasic.forum@zbasic.net)> wrote:
Have you changed the battery brand or type you are using?
On Aug 24, 2015, at 6:12 AM, ZBasic <zbasic.forum@zbasic.net (zbasic.forum@zbasic.net)> wrote:
all sound like very sensible suggestions, but I keep coming back to the fact it has worked for nearly 3 years without these issues, so amending the design, whilst to recommended standards would not appear to be indicated at this stage. I'd like to get back to a stable known point before making modifications although most sound like they should be planned in anyway.
We'll see how the fix performs this weekend.
?will apply the caps as suggested. to be clear .1 between any unused ground and/or VCC pins on the processor board and ground
ALL of the Vcc and Ground pins on the micro are used.
None of them should be left unused, (unconnected).
And yes, the By-Pass caps go from the Vcc and AVcc pins to Ground.The issue is that the M128 has two Vcc and an AVcc pin.
ALL of them need to be connected to Vcc.
All three of the Grounds need to be connected to Ground.
Both of the Vcc and the AVcc pins should have a By-Pass cap, typically a 0.1 uF cap placed as close to the micro's pins as possible.
JC
the project is based on one of these
https://www.sparkfun.com/products/retired/9546
as you can see it has 2 ground pins and I need to check that both are connected.
The avcc is used as it has a battery level monitor function.
thanks
https://www.sparkfun.com/products/retired/9546
as you can see it has 2 ground pins and I need to check that both are connected.
The avcc is used as it has a battery level monitor function.
thanks