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?
Martin White <martin@guddler.co.uk> wrote: Isn't this just sounding more and more like a simple case of a faulty
eprom that needs discarding?
On Tue, October 3, 2006 1:53 pm, 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
>
>
>
> John Robertson wrote: Yes, Cameron, the 2532
> does go to FFFh, a 2716 fills to 7FFh.
>
>
> If you have a logic probe with a 'memory' you can use that on a read to
> see if the A11 toggles. You can use a voltmeter as well...Pin 12 is Gnd,
> I would stuff thin wires into the two socket opening and clip the
> voltmeter to them.
>
>
> If it toggles on a read (it will start Low, then go High at 800h) but
> not on write (write FFs that you just 'read') then you have more
> information.
>
>
>
>
> John :-#)#
>
>
> At 6:02 PM -0700 10/1/06, Cameron Rector wrote:
> Rodger, Thanks for the input however, I believe the last address for
> the 2532 is FFFh. The 2532 is a 32k device arranged as 12bit address
> 8bit data or 4096x8=32k. I'm a little rusty at this but I also think
> that 7FFh = 2048 and 4096 = FFFh. With this said; I still think I
> have something wrong with my A11 signal or signal path. If you can
> think of something else, please let me know. Cameron
>
> Rodger Boots wrote:
> Cameron Rector wrote:
>> Hello all,
>> I am new to this site, so I will applogize for dumb questions up front.
>>
>> I have a Bytek fireman 8x and I am having trouble programming
>> TMS2532A's. The programming part goes well until verify. It seams that
>> at address 0800h it fails. It does this on every chip I try. I don't
>> know if this could be a configuration setting or it the unit has a bad
>> solder joint or IC. I did a visual inspection from A11 pin 18 back
>> through the circuit traces and joints, however I didn't find anything
>> wrong. I tried to call Bytek and their phone is disconnected and my
>> email bounced back.
>>
>> So, does anyone here know anything about this machine? Does anyone know
>> where I can get the schmatic's for this programmer?
>>
>> I am a newbe at programming eproms, so don't overlook the fact I could
>> have a software setting wacked out.
>>
>> The first verify error says "ADDS 0800h Ram 01 Device 00"
>
>
> That's OK, the last address in a 2532 would be 07FF, so at 0800 you're
> no longer inside the 2532.
>
> You have the end of buffer set too high, otherwise it would have stopped
> at 07FF.
> _______________________________________________
> Techtoolslist mailing list
> Techtoolslist@flippers.com
> http://seven.pairlist.net/mailman/listinfo/techtoolslist
>
>
> _______________________________________________
> Techtoolslist mailing list
> Techtoolslist@flippers.com
> http://seven.pairlist.net/mailman/listinfo/techtoolslist
>
>
>
>
> --
> John's Jukes Ltd. 2343 Main St., Vancouver, BC, Canada V5T 3C9
> Call (604)872-5757 or Fax 872-2010 (Pinballs, Jukes, VideoGames)
> www.flippers.com
> "Old pinballers never die, they just flip out"
> _______________________________________________
> Techtoolslist mailing list
> Techtoolslist@flippers.com
> http://seven.pairlist.net/mailman/listinfo/techtoolslist
>
> _______________________________________________
> Techtoolslist mailing list
> Techtoolslist@flippers.com
> http://seven.pairlist.net/mailman/listinfo/techtoolslist
>
_______________________________________________
Techtoolslist mailing list
Techtoolslist@flippers.com
http://seven.pairlist.net/mailman/listinfo/techtoolslist
_______________________________________________
Techtoolslist mailing list
Techtoolslist@flippers.com
http://seven.pairlist.net/mailman/listinfo/techtoolslist
Received on Thu Oct 5 12:13:06 2006
This archive was generated by hypermail 2.1.8 : Thu Oct 05 2006 - 13:50:00 EDT