From PICLIST@MITVMA.MIT.EDU Fri Nov 15 02:31:26 2002 Received: from cherry.ease.lsoft.com [209.119.0.109] by dpmail10.doteasy.com with ESMTP (SMTPD32-7.13) id ACFE15B100A0; Fri, 15 Nov 2002 02:31:26 -0800 Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <1.007DB55D@cherry.ease.lsoft.com>; Fri, 15 Nov 2002 5:17:24 -0500 Received: from MITVMA.MIT.EDU by MITVMA.MIT.EDU (LISTSERV-TCP/IP release 1.8d) with spool id 0492 for PICLIST@MITVMA.MIT.EDU; Fri, 15 Nov 2002 05:17:05 -0500 Received: from MITVMA (NJE origin SMTP@MITVMA) by MITVMA.MIT.EDU (LMail V1.2d/1.8d) with BSMTP id 5898; Fri, 15 Nov 2002 05:15:41 -0500 Received: from nameserv.rl.ac.uk [130.246.135.129] by mitvma.mit.edu (IBM VM SMTP Level 320) via TCP with ESMTP ; Fri, 15 Nov 2002 05:15:40 EST X-Comment: mitvma.mit.edu: Mail was sent by nameserv.rl.ac.uk Received: from sstdwkiwi (sstdwkiwi.ag.rl.ac.uk [130.246.189.231]) by nameserv.rl.ac.uk (8.8.8/8.8.8) with SMTP id KAA27255 for ; Fri, 15 Nov 2002 10:15:41 GMT References: X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Message-ID: <012301c28c8f$f3b25d80$e7bdf682@sstdwkiwi> Date: Fri, 15 Nov 2002 10:15:41 -0000 Reply-To: pic microcontroller discussion list Sender: pic microcontroller discussion list From: "Alan B. Pearce" Subject: Re: [PIC]: Detecting SRAM and eeprom To: PICLIST@MITVMA.MIT.EDU X-RCPT-TO: Status: R X-UIDL: 277600624 X-Evolution-Source: pop://mailinglist%40farcite.net@mail.farcite.net/ Mime-Version: 1.0 X-Evolution: 00000748-0000 >The problem is in the read after write to the same location. On many cmos >buses the bus capacitance will store state between the read and write and >the test will succeed even if there is no part at that address. I did not >dream this up, it really happens all the time and I do take this into >account. Which is why it is good ractice to have pull up or pull down resistors, and when doing such tests always write a pattern with both 1's and 0's in it. One free guess why the standard IBM PC POST writes alternating 0xAA & 0x55 to adjacent locations. It saves the exact capacitive storage problem you have just described from affecting the read action. -- http://www.piclist.com hint: The PICList is archived three different ways. See http://www.piclist.com/#archives for details.