Date: Fri, 25 May 2001 19:57:32 +0300 From: "Eli Zaretskii" Sender: halo1 AT zahav DOT net DOT il To: "Alex Oleynikov" Message-Id: <1659-Fri25May2001195731+0300-eliz@is.elta.co.il> X-Mailer: Emacs 20.6 (via feedmail 8.3.emacs20_6 I) and Blat ver 1.8.9 CC: djgpp AT delorie DOT com, Charles Sandmann In-reply-to: <001a01c0e530$e72a3db0$1400a8c0@alex2000> Subject: Re: SRAM chip access problem References: <001a01c0e530$e72a3db0$1400a8c0 AT alex2000> Reply-To: djgpp AT delorie DOT com Errors-To: nobody AT delorie DOT com X-Mailing-List: djgpp AT delorie DOT com X-Unsubscribes-To: listserv AT delorie DOT com Precedence: bulk [Please don't post in HTML.] > From: "Alex Oleynikov" > Date: Fri, 25 May 2001 11:39:36 -0400 > > Can anyone give me a hint why my simple attempt to access an NVRAM chip = > (128K Dallas Semiconductor plugged into DiskOnChip socket) from within a = > DJGPP program crashes instantly (DOS v.7 (taken from Windows 98) + = > CWSDPMI v.r4 + DJGPP v.2.03)? Are you really using CWSDPMI r4? If so, I suggest to upgrade to r5. > Here's portion of the code trying to peek at the data: > > mapping.size=0x80000; > mapping.address=0xfff80000; Are these the correct address and size of the on-device memory? If 128K is the size of the device's memory, you should be setting size to 0x20000, not 0x80000. > selector = __dpmi_allocate_ldt_descriptors(1); > __dpmi_set_segment_base_address(selector, mapping.address); > __dpmi_set_segment_limit(selector, mapping.size-1); You don't check the return values of these three function calls. Judging by the crash message, they did work (see the base address and the limit of the selector loaded into the FS register), but you should really modify the program to verify that these function calls succeeded before you use the selector. (Yes, I know you lifted the code from the FAQ, but the FAQ only outlines what should be done, it's not production-quality code.) > byte = _farpeekb(selector, 0); > ... > > Here's the result: > > Exiting due to signal SIGSEGV > Page fault at eip=0000354a, error=0004 > eax=000000c7 ebx=00001000 ecx=00000007 edx=00000000 esi=0000054 edi=000923c9 > ebp=00092270 esp=00092270 program=C:\CD4000\PROBE.TC\SRAM.EXE > cs: sel=00a7 base=10000000 limit=0009ffff > ds: sel=00af base=10000000 limit=0009ffff > es: sel=00af base=10000000 limit=0009ffff > fs: sel=00c7 base=fff80000 limit=0007ffff > gs: sel=00bf base=00000000 limit=0010ffff > ss: sel=00af base=10000000 limit=0009ffff > App stack: [000923f0..000123f0] Exceptn stack: [00012350..00010410] This means something is wrong with mapping the device into your program's address space. You can see that the FS selector is loaded with the values you passed when you called __dpmi_set_segment_base_address and __dpmi_set_segment_limit. However, Page Fault means that the resulting address is not accessible by you (error=4 means you tried to read from that address, which is expected for a call to _farpeekb). My guess would be that either your address and/or limit are wrong for the device you want to access, or maybe there's some bug in CWSDPMI (thus the advice to upgrade). Wait a minute: something _is_ wrong with the selector you got from __dpmi_allocate_ldt_descriptors: it seems to be a selector for code, not for data (bit 3 of the selector is 0 instead of 1). Can you call __dpmi_set_descriptor_rights to set the data-segment bit, before the call to _farpeekb, and see if that solves the problem? Charles, shouldn't the selector returned by __dpmi_allocate_ldt_descriptors be set to data by default? The DPMI spec seems to say it should.