GXS-700 Memories

As were shown in previous post the GXS-700 sensor has a 8 KBytes EEPROM and a 16 MBytes SPI Flash. It is quite interesting as the devices are almost empty, being posible that the flash were intended to store the calibration images (more on these on a later post) but the files are provided separately from the sensor, usually on a CD.
The sensor I disassembled was not operative and I was not able to retrieve the EEPROM and Flash contents using John McMaster's driver, but as I had already open the devide I desoldered the devices and read them using a TL866 memory reader.
It was a surprise to discover that the EEPROM had the serial number erased. This is a known issue on these sensors and some users claim it is caused by a bug in the Cypress SDK.
As shown in the following image the serial number area (highlighted in red) is blank:

Other interesting areas in the EEPROM are the ones highlighted in orange/yellow, that match the description in Cypress EZ-USB Technical Reference Manual, where 0xC0 indicates that the EPPROM contains the VID/PID/DID to be used for USB enumeration, and the 0x01 configures the I2C bus to operate at 400KHz.

After the USB/I2C configuration follow two 32-bit integers (note that ALL the multi-byte data is stored in little-endian format) that are incremented with every capture of the sensor (using forced capture in John's driver both counters increment by one unit, but I do not have any operative sensor, so I don't know what happens if the sensor triggers by normal operation or which is the difference between the two counters).

As shown in the image only 80 bytes of the 8KBytes memory are used.

It is posible to fix the serial number in EEPROM by dumping the EEPROM contents using John's driver "dump-dev.py --eeprom". Once you have the binary file open it using an hexadecimal editor and enter the serial number starting at address 0x40 (red area above). The serial number has a CRC that can be calculated using this CRC-calculation page:

Select CRC-CITT first. Then change the fields highlighted in red as shown in the image. Enter the serial number in decimal format and press "compute!". You'll get the CRC (highlighted in blue in the example above) in hexadecimal format.

The serial number CRC needs to be written in the EEPROM as shown in the image below (note the zeroes that also need to be added highlighted in blue). The CRC need to be 4 hexadecimal digits, so complete with leading zeroes if required:

Obviously, to be able to fix the serial number you need to know it. The serial number value can be retrieved from the USB cable sticker that also holds the reference and manufacturing date:

Or, if the cable doesn't have the sticker the serial number can also be retrieved from the Flash image that can be dumped using John's driver "dump-dev.py --flash" (serial number highlighted in green in the image):

As can be seen only 532 bytes of the 16MBytes Flash are used!

Ii is interesting to note that after the signature (boxed in red) the Flash contains two 32-bit integers holding the sensor resolution (1346x1850 for Gendex Size 2 sensors and 1346x1700 for Dexis ones).

The Flash also contains a manufacturing date matching the cable one, and several version numbers (maybe of the FPGA firmware components).

Although the resolution stored in EEPROM is different it looks like both Gendex and Dexis use the same hardware, with the same physical CMOS sensor. 

GXS-700 Internals

Thanks to the great blog by John McMaster (uvicrec.blogspot.com) I knew of the intraoral dental x-ray sensors sold by Gendex and Dexis. I liked the post so much that I bought some of these that were offered at eBay as non-working or calibration files missing.
The driver provided by John allowed to connect to the sensors and play around, but the test for "dark" image indicated that the sensors where not working properly. This was not a surprise for the sensors listed as non-working, but I did expect that one listed as "missing calibration files" would work, as the original software requires the files to work, but John's software doesn't.
Some of the sensors seem to provide random noise while others provide a black image. Having non-working devices I decided to investigate if I could find the reason of the failure, as while some sensors looked like abused at least one looked like new.
One of the sensors was heavily abused with visible damage on the outside (this was unfairly listed as not-tested, despite the fact that the phisical damage was evident...beware of chinese Sellers!!).
This one did not enumerate when conected to a PC, so I decided to open it up, revealing shuttered sensor and scintillator glass, and also a bent PCB, which would be the main cause of electronic failure due to broken BGA solder balls.

You can find details of the Gendex GXS-700 sensor in the Wiki (another great job done by John McMaster) at www.siliconpr0n.org/nuc.

Despite the great detail provided in the Wiki I found out some additional information on the components of the PCB.

The highlighted ICs are:

• Actel ProASIC3 A3P250 FPGA (yellow)
• LTC2355 Serial 12-Bit/14-Bit, 3.5Msps Sampling ADC (green)
• MT45W4MW16PCGA 64Mb: 4 Meg  x 16 Async/Page CellularRAM (purple)
• CY7C68013A EZ-USB FX2LP USB Microcontroller (orange)
• LT3547 Dual Monolithic 300mA Synchronous Step-Down Regulator (brown)
• Microchip 24LC64 8KB serial I2C EEPROM (red)
• Spansion FL128PIF 16MB SPI Flash (blue)

The I2C and Flash contents (it looks like only a very small área is used) can be retrieved using John's software (more on this on next entry).