From: "Finn Lassen finn.lassen@verizon.net" <flyrotary@lancaironline.net>
Received-SPF: pass
 receiver=logan.com; client-ip=66.163.184.201; envelope-from=finn.lassen@verizon.net
Subject: Re: EC2 progress
To: Brayton Hackbarth <brayton.hackbarth@gmail.com>
References: <CAP7UBP=KoxzQpLC--1L9mjoYpHCbfc2th4d3yve4Y=TDV6SgeA@mail.gmail.com>
Cc: flyrotary@lancaironline.net
Message-ID: <310c62be-9a34-da25-9335-3ba015e80121@verizon.net>
Date: Mon, 14 Feb 2022 15:26:33 -0500
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:52.0) Gecko/20100101
 Thunderbird/52.9.1
MIME-Version: 1.0
In-Reply-To: <CAP7UBP=KoxzQpLC--1L9mjoYpHCbfc2th4d3yve4Y=TDV6SgeA@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Content-Length: 3210

Hi Brayton,

Sure looks like you've made very good progress. I suspect you'll be 
another go-to or expert on the EC2, in addition to Steve Izett.

Yes, would have been a lot easier to have the config bits set in the 
code. I know Steve added that to his  EC3 source code.

The filter cap on the MCLR line is always a good idea if you're not 
going to do in-circuit (CPU chip installed on the board) programming.

A low-noise installation is definitely a must, even though there is some 
supply filtering on the EC2 board, I think. Good grounds are essential. 
Reading through Tracy's EC development log where he visited someone that 
had EC problems and found poor grounding, is eyeopening.

If you found corrosion on the board, how about the external connectors 
and wiring?

Good luck with the N767TX.

Finn

On 2/14/2022 12:51 AM, Brayton Hackbarth wrote:
> Hello Finn,
>    I've made good progress on the EC2. If you want to share this any 
> other rotary folks that might be interested, feel free.
>  First the board was cleaned of visible corrosion. Some of the 
> corrosion appeared to bridge a couple solder points on A, so I noted 
> which those were.  Next, I took backups of the A and B chips. They 
> were nearly identical except for different binary data at the end. 
> Interesting that I can read 183KB off the chips but when I build the 
> source I get a 20KB hex file.
>
> In learning to dump and program chips I learned about the MCLR line. 
> Pulling that low resets the chip. Putting noise on it makes the chip 
> rapidly reset and bounce all over the place. I saw that Tracy made 
> repeated comments in the source code about disabling the MCLR line via 
> config bits. But much later he documented putting on a .01 filter cap 
> on a couple boards to keep them from resetting due to electrical 
> noise. I then realized that the MCLR line was where some of the 
> corrosion I cleaned on the board was, on side A. The MCLR line is very 
> near an injector driver line.  A correctly-set config bit should 
> negate the need for a .01 filter cap. Grandpa's board lacked both the 
> filter cap and I think the MCLR config bit being disabled (need to 
> hook it back up to PICkit to confirm).  Both BOR (brown out reset) and 
> MCLR need to be disabled for stability when flying due to electrical 
> noise or corrosion. Since I wasn't confident in my software builds 
> yet, I added a .01 filter cap to the MCLR line on side A, so the cap 
> must discharge fully before that gets pulled low. The engine was run 
> today successfully, waiting to see if the problem re-appears.
>
> Tracy didn't set the config bits in the code, but instead must have 
> set them per-programming session. This gave me trouble as they would 
> go back to default at next project load. For my own builds I've made 
> an include file that sets the necessary config bits at run-time (BOR 
> off and MCLR off). Thanks a lot for the code, it taught me a lot and I 
> think I'm close to building a working ROM for N767TX
>
> Best Regards
> --Brayton Hackbarth CFI
> https://hackbarthcommunications.com
>
>


---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus