6502.org Forum  Projects  Code  Documents  Tools  Forum
It is currently Sun Nov 24, 2024 12:08 am

All times are UTC




Post new topic Reply to topic  [ 10 posts ] 
Author Message
PostPosted: Thu Nov 30, 2023 12:13 am 
Offline

Joined: Fri Jul 09, 2021 10:12 pm
Posts: 741
I've just spent an evening struggling with odd behaviour from an AT28C64B EEPROM. It's worked fine for a long time, but today after reprogramming, it started to fail. Initially of course I assumed there was a problem with my new code, or a loose wire elsewhere in the circuit, but I ended up tracing it back to the EEPROM.

I believe what I did was accidentally try to program it as an AT28C256E. I'm sure it's not the first time I've done this by accident, but it's the first time it's apparently caused damage to the IC.

The result is that, in my circuit, the EEPROM seems to always read $FF from every byte. Especially the low byte of the reset vector should be $00 but reads as $FF, this one is easy to spot but I suspect it's the case for all addresses. However, one of the first things I tried when I saw odd behaviour immediately after reset was putting the EEPROM back in the programmer and hexdumping its contents - and the readback was perfectly fine. So I started to suspect other things, such as accidentally enabling RAM or some other chip on the data bus at the same time - but after eliminating all those possibilities, I had to come to the conclusion the EEPROM was faulty.

Testing it in isolation in my own test rig also produces the same failure result. However, because it was working fine when read back by the programmer, there was clearly more going on here. I began to suspect that either it was something to do with the unlocking protocol, or the "no connect" pins (1 and 26, which would be A14 and A13 on a larger EEPROM) might be having some effect. They were tied high in my test rig, but sure enough, if I disconnected them, the voltage on the data pins when presented with address $1FFC - which should have been zero - at least dropped from 5V to about 3.8V. And if I connected the "no connect" pins to ground, then the voltage dropped all the way down to 0V as it should be. I tried other addresses and found that the data pins did still go high when they should.

So the problem in my computer circuit is that I have these pins connected to the address bus, so that I can support 32K EEPROMs as well. However, now in order to support this 8K EEPROM, I'll need to tie them low instead.

These pins are documented as "no connect" in the datasheet (page 2 of https://ww1.microchip.com/downloads/en/ ... oc0270.pdf) and it makes a distinction to some "don't connect" pins that exist in the PLCC package version. But clearly in this case "no connect" doesn't mean they haven't physically connected them to anything - whatever they're connected to, while it may be generally inert, must have been fused by the programmer when trying to program it in AT28C256E mode, and is now leading to something like leakage from those pins to ground perhaps? Or at least, data pins that are meant to be low read as high or intermediate levels now.

I'm curious whether you guys have seen this before, and whether you think connecting to these pins is bad practice in general - my understanding was always that, while what different manufacturers mean by "no connect" can vary, for these memory ICs with standard pin layouts it was meant to be the case that smaller ones would just ignore what level was presented there, so it was fine to provide whatever signal you liked. I suspect that's still the case, except I broke this one!


Top
 Profile  
Reply with quote  
PostPosted: Thu Nov 30, 2023 5:04 am 
Offline

Joined: Mon Jan 19, 2004 12:49 pm
Posts: 988
Location: Potsdam, DE
I've not seen this particular fault, but I have always understood 'no connect' as 'do not connect' rather than 'internally non-connected' - some manufacturers use these NC pins as test points.

A handbag link to specify whether the pins are connected to an address bus or left open is messy but would work if you have the board real estate available.

Neil


Top
 Profile  
Reply with quote  
PostPosted: Thu Nov 30, 2023 5:59 am 
Offline
User avatar

Joined: Thu May 28, 2009 9:46 pm
Posts: 8513
Location: Midwestern USA
Quote:
These pins are documented as "no connect" in the datasheet...

Like Neil says...a “no connect” means just that: the pin is to be left unconnected...floating.  At best, the device may misbehave if a “no connect” is connected to something.  At worst, you may end up converting the device into a small paperweight.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!


Top
 Profile  
Reply with quote  
PostPosted: Thu Nov 30, 2023 10:51 am 
Offline

Joined: Sun Jul 11, 2021 9:12 am
Posts: 155
BigDumbDinosaur wrote:
Quote:
These pins are documented as "no connect" in the datasheet...

Like Neil says...a “no connect” means just that: the pin is to be left unconnected...floating.  At best, the device may misbehave if a “no connect” is connected to something.  At worst, you may end up converting the device into a small paperweight.


Minor pedantic note™ - At best, the device will work perfectly if a “no connect” is connected to something. :D


Top
 Profile  
Reply with quote  
PostPosted: Thu Nov 30, 2023 4:37 pm 
Offline

Joined: Fri Jul 09, 2021 10:12 pm
Posts: 741
I see, thanks guys. Well, no harm done, except now I must connect them or it doesn't work at all!


Top
 Profile  
Reply with quote  
PostPosted: Thu Nov 30, 2023 7:25 pm 
Offline
User avatar

Joined: Thu May 28, 2009 9:46 pm
Posts: 8513
Location: Midwestern USA
J64C wrote:
Minor pedantic note™ - At best, the device will work perfectly if a “no connect” is connected to something. :D

No sir.  Unless the data sheet explicitly states that a “no connect” pin has no internal connection, such an assumption is fallacious.  In some cases, a “no connect” pin may be used during production to test the device.  If that is the case, connection of a “no connect” pin in the application circuit becomes an undefined configuration.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!


Top
 Profile  
Reply with quote  
PostPosted: Thu Nov 30, 2023 8:50 pm 
Offline
User avatar

Joined: Thu Dec 11, 2008 1:28 pm
Posts: 10986
Location: England
It's not an assumption, but a possibility, that nothing goes wrong - and it's possible - and it's a best case. It's just logic!


Top
 Profile  
Reply with quote  
PostPosted: Thu Nov 30, 2023 9:03 pm 
Offline

Joined: Sun Jul 11, 2021 9:12 am
Posts: 155
BigEd wrote:
It's not an assumption, but a possibility, that nothing goes wrong - and it's possible - and it's a best case. It's just logic!


Yup! Exactly what I was getting at. :D

Ideally leave it unconnected, but best case scenario nothing will go wrong, worst case scenario your circuit doesn’t work.


Top
 Profile  
Reply with quote  
PostPosted: Fri Dec 01, 2023 4:11 am 
Offline

Joined: Wed Aug 21, 2019 6:10 pm
Posts: 217
J64C wrote:
BigEd wrote:
It's not an assumption, but a possibility, that nothing goes wrong - and it's possible - and it's a best case. It's just logic!


Yup! Exactly what I was getting at. :D

Ideally leave it unconnected, but best case scenario nothing will go wrong, worst case scenario your circuit doesn’t work.


Best case, no problem, median case, the circuit just doesn't work, worst case, you release the magic blue smoke.


Top
 Profile  
Reply with quote  
PostPosted: Fri Dec 01, 2023 8:46 am 
Offline
User avatar

Joined: Thu Dec 11, 2008 1:28 pm
Posts: 10986
Location: England
Worst case, you get intermittent failures and spend a lot of time trying to debug!


Top
 Profile  
Reply with quote  
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 10 posts ] 

All times are UTC


Who is online

Users browsing this forum: Google [Bot] and 63 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to: