2

I am trying to read an Atmel 93C56B eeprom, so8 surface mount package, with this programmer. When using the so8 adapter in the zif socket it works perfectly. However when I use the test clip, it is giving me read errors on every other bit. The errors are consistent and seem to happen with every bit value except FFFF.

The test clip works fine when writing data also.

In every case (except FFFF), the even numbered bits (0,2,4,...) return the correct value, and the odd ones are wrong.

I am guessing this has to do with the length of the leads, however I even shortened the lead length by 75% and still have this problem. I have also tried 8dip versions of this eeprom in this same programmer and they never give errors so I must assume it is the clip. I have checked the pins of the clip and they are all correct (and if they weren't it shouldn't be able to write to the eeprom)

If this were a serial port I might try slowing down the bitrate, but this programmer seems to have no settings at all.

The reviews for this clip dont mention this problem, and it is sold by the same company that sells the programmer.

edit: btw the chip being accessed with the test clip is not soldered to anything

enter image description here

chuck333
  • 21
  • 2
  • And here is the Chinese manufacturer of the programmer: http://www.autoelectric.cn/EN/TL866_MAIN.html – chuck333 Jan 10 '16 at 23:15
  • This site is so difficult to use! These reputation limits on posting no more than 2 links is completely retarded! – chuck333 Jan 10 '16 at 23:17
  • 2
    Well then consider earning some reputation. – Nick Alexeev Jan 10 '16 at 23:37
  • Thanks for fixing that for me Nick; it considered uploaded pics as links for some reason. I intend to earn reputation lol, as soon as possible – chuck333 Jan 10 '16 at 23:56
  • @chuck333 I'm sure it's an adaptation to spamming or something of that ilk. Otherwise the site could be inundated with useless links (useless except for the commissions paid to spammers). – Spehro Pefhany Jan 11 '16 at 01:00
  • You won't be able to change the firmware in the programmer most likely, so I suggest you should talk to the maker first (since both items came from them). If desperate you could try something like 33R or 51R in series with the clock line, that might make it work. – Spehro Pefhany Jan 11 '16 at 01:03
  • P.S. I mean at the programmer- it's too late at the other end of the cable. – Spehro Pefhany Jan 11 '16 at 01:16
  • @sphero Thanks for the suggestion; I am in the process of doing that, however with such Chinese tech it is a crap shoot where that will get me lol. Forgive me, by 33R/51R what exactly do you mean? I see multiple different components with those designations. Im guessing whatever it is it would slow down the clock signal to allow the data line to catch up? (I still have no idea why it would work fine on the write and mess up the read every time, however.) Thanks again – chuck333 Jan 11 '16 at 03:33
  • My gut tells me this is not a programmer-specific problem however, seeing as how it repeats every time and only with the read mode. Does anyone see any clues in the way the bits are misread perhaps? – chuck333 Jan 11 '16 at 03:37
  • Ok so I tested a theory- in which i replaced the clip and leads with standard 12" solderless breadboard jumper wires. Also I substutited one of the 93C56B 8DIP chips for the SO8. This reads fine with the longer leads; however the original SO8 now reads errors in every bit. (Still writes fine however) – chuck333 Jan 11 '16 at 04:01
  • You don't happen to have an oscilloscope lying around that you could use to look at the I²C signals? – CL. Jan 11 '16 at 09:41
  • I do actually. That is a great idea, however my expertise may not be sufficient to gain any useful information from such... I have determined it is an issue with those specific chips. I tried it with another 93c56 from another vendor and it worked fine. Really weird. I think Ill give Atmel a call. Still would love to know why it happened and why only the second bit corrupts like that. – chuck333 Jan 11 '16 at 22:33
  • missing decoupling capacitor near to the chip? Long leads without capacitor my show some problems. – WalterH Jan 17 '16 at 15:21
  • As data in and data out are on different pins, it is perhaps not surprising that errors can be on read and not write. I would be suspicious of the cable on the read pin. The EEPROM can only drive a couple of mA, and a large capacitance could give you these errors; it could also change the read timing parameters which could also be an issue. – Peter Smith Jan 17 '16 at 15:48

0 Answers0