Cannot read from DAQCard calibration EEPROM

[JamieB]

I am not able to read the calibration EEPROM from either a DAQCard-6036E or DAQCard-AI-16XE-50.  I have tried all code examples I could find in the forums and in all cases I just get all zeroes for the content. 

There have been others who have had the same problem, but NI tech support suggested that I post a new thread in this forum before they escalate my support case, so I am creating a new post rather than adding to an old one.  Here are a couple threads that I found, but so far I have not seen any answers (note that in the first link the code that was posted worked for some people, but not others):

http://forums.ni.com/ni/board/message?board.id=250&message.id=3218

http://forums.ni.com/ni/board/message?board.id=250&message.id=842

All other functionality is working fine and I verified that I am able to write something to the calibration DACs by sending bogus values and observing that my measurements change. 

My theory right now is that the problem is due to the way the Intel PXA255 processor in my PDA handles 8-bit reads on the PCMCIA bus.  While searching for a solution, I have come accross such statements as: "8-bit Memory Read access cycles are not supported by the PXA255 PCMCIA controller for common memory space."  and "Be careful of 8 bit access to the device there is a known problem with the PXA250 PCMCIA/CF card interface where an 8 bit access will actually generate a 16bit read on the bus".   The PXA Developer Guide appears to confirm this also. 

I came across a post that suggested directly manipulating the CE2 I/O line via the PXA255 GPIO registers (note that 86 refers to the chip Errata number), but did not have any success with it (yes, I did use MmMapIoSpace to access the GPIO registers and replaced the comments with code that actually sets the register values):

UCHAR Errata86ReadByte(UCHAR* pAddr)
{
    UCHAR retVal;
    EnterCriticalSection(&csErrata86);
    // Set GPIO Socket 0 CE2 Alt Function to 0 (Disable PCMCIA functionality
    // Set GPIO PIN for Socket 0 CE2 to high state
    retVal = *pAddr;
   // Set the GPIO Socket 0 CE2 Alt Function to 2 (re-enable PCMCIA 
controller use of the pin)
   LeaveCriticalSection(&csErrata86);
   return retVal;

}

Has anyone had the same problem and figured out a solution?  Am I mistaken about the PXA255 8-bit reads on the PCMCIA bus?

[Jeremy_C]

What kind of PDA are you using?  I was able to read the calibration constants from the EEPROM of a DAQCard-6036E on an iPAQ h5555 (PXA255 processor) with NI-DAQmx Base and LabVIEW PDA.  What address offsets are you reading from for the 6036E?  On a side note, I do recall being unable to read from the EEPROM on a 6036E using an iPAQ 3900.  So, it does appear that there are peculiarities with individual PDAs.  Have you tried a different PDA?

[JamieB]

I am using an inHand ELF3 (http://www.inhand.com/elf.asp) with WINCE 4.2.  I have tried using both the NI-RLP driver and another 'custom' driver - both of which give the same result, but I have not tried with LabView. 

I am writing to address 0x0D (serial command register) to bit-bang the serial bus, and reading from 0x01 (status register) to get the EEPROM output.  Since the CALDAC write seems to work, at least the serial command register address should be okay.

Unfortunately I do not have another PDA with a PCMCIA slot to try out.  There is really no option for me to switch to another PDA model even if it solves the problem, because the PDA is integrated into a larger system.  In the worst case I may have to read the factory calibration values from the EEPROM using a laptop or desktop machine, and then generate a file that the application on the PDA would read on initialization (i.e. in place of reading from the EEPROM).

I will take a look and see if I can find anything that the iPAQ 3900 and my PDA have in common and is different from the iPAQ h5555. 

Thanks for the reply.

[Jeremy_C]

Ah, I worked with a customer a little over a year ago that was having the same problem with an ELF3.  He was able to successfully read the calibration coefficients on an HP iPAQ h5550 (similar to my h5555) with the same code that didn't work on his ELF3.  We concluded that the ELF3 had the same 8 bit read problems that we had seen on the iPAQ 3900.  I believe he contacted the manufacturer of the ELF3 to try to resolve this behavior.  But he did mention implementing a short term solution similar to what you are describing, where you read the calibration coefficients from a device that supports 8 bit reads.  I hope this helps.  Let me know if you have any other questions.