Re: Programmer troubles with a new twist.

Ok, I tried the pull-up resistor idea and there was no change.
   
  What I did find was address 800h contains the same data as 000h and 801h = 001h and so on. It appears that the programmer is resending the first half of the ram to 800h and above.
  I only checked the first 8 addresses and the data matches, so I assume that it continues.

  The programmer has internal memory and when I query 800h it has the correct data stored there.
   
  I looks like it programs the first 2048 in the bottom half of the eprom and then programs the first 2048 in the top half of the eprom.
   
  Anythoughts other than the trash can?
  
Rodger Boots <rlboots@cedar-rapids.net> wrote:
  Cameron Rector wrote:
> First of all; I have to say my troubles are looking more and more self
> induced.
>
> I talked to some people on the techtool fourm and got a tip to watch A11
> with a logic probe while programming. Well intresting enough; A11 goes
> high right at 800h and stays high though the rest of the programming
> (that is what it shoud do). So this got me thinking of performing a few
> more tests.
>
> 1. first I loaded a blank eprom into ram, then I viewed the ram and saw
> it was filled with FF (which is correct). Then I performed a verify and
> it passes (and it should). I next loaded my binary file (I am assuming
> its binary) and re-ran verify and it fails (and it should). Then I
> program the ram (containing the file) into the eprom and the post
> program verify fails (and it should not). So I see it fails at 800h (as
> it always does) and it shows ram = 00 and the device = A2 (or something
> simular, I forgot the exact number). So at this point I see from 800h on
> things don't match up. I next load ram again with FF just to make sure
> it is clear and then download the device into ram. I then view the ram
> at 800h and it says 800h = 00. I again run verify and again it fails at
> 800h saying the same thing ram = 00 and the device = A2.
>
> Now how the heck can that happen? I just downloaded the device into ram
> and verified it against its own contents and it fails showing it has a
> different number than what it downloaded.
>
> 2. Just to test the hardware of the programmer. I verified a new blank
> eprom and it passed all FF. I then loaded a constant 00 into ram and
> programmed the eprom and it passes. This tells me that I can take all
> highs at all pins and change them to all lows at all pins. This also
> tell me that the programmer must be doing the hardware thing correctly.
>
> 3. I programmed another blank eprom with an abitrary constant CC and it
> passes. CC is loaded in all locations.
>
> I hope you can follow all of this.
> Thank you for all the help folks!
> Cameron

Definitely a programmer problem. As an experiment, try adding a 4.7 K
(or 4K7 if you're European) resistor from the A11 line to 5 volts at the
EPROM and see if the problem goes away.

Yes, the programmer is taking the A11 line high, BUT HOW FAST. If the
driver is bad (or missing a pullup resistor, if used) you could be
seeing the contents of 0000 instead of 0800 momentarily. To have the
problems you have this would have to be a VERY borderline timing issue.

---------------------------------------------------------------------------
** Unsubscribe, subscribe, or view the archives at http://www.vectorlist.org
** Please direct other questions, comments, or problems to chris@westnet.com

---------------------------------------------------------------------------
** Unsubscribe, subscribe, or view the archives at http://www.vectorlist.org
** Please direct other questions, comments, or problems to chris@westnet.com
Received on Thu Oct 5 11:32:52 2006