I received this device today Envoy Data 4GB CF, user connected the card upside down and can't access the data, when I look at it, card comes "ready" with capacity of 128GB. I don't own any flash reader as right now, could somebody please guide me to what components I could check to see if I can't get it going?

Thank you

Unfortunately it's not as simple because no way to get layout of PCB and pcb components.
Worth to check resistors (black elements Rx).
Chip-off would be ideal solution here, this controller is pretty simple to recover and good NAND chips (double-crystal package).
[Unite by bytes-->Inversion--> Pair-->Unite by virtual page (1 virt.page = 4 x ph.pages)]. Then Logical Block translation algorithm which is also simple in this controller.

_________________
VISUAL NAND RECONSTRUCTOR. A big revolution in chip-off data recovery

The pinout of the CF connector suggests that reversing the connector should still maintain the same positions for the VCC and Ground pins, so one would expect that there should be no catastrophic damage. It only remains to be seen whether the I/O pins can tolerate such a reversal, but experience with 40-pin HDD IDE cables would suggest that they would normally be idiot proof.

http://pinouts.ru/Memory/CompactFlash_pinout.shtml

I can't see that there is much for you to do other than to verify whether +3.3V is present at the NAND chips. To this end you would measure the voltage across C1, C2, C3, C4, or C5.

You should also confirm that the CF card identifies itself correctly in other respects (to confirm that there are no stuck data bits on the IDE interface).

BTW, U5 appears to be reserved for an external +3.3V linear regulator. It is needed by earlier controllers that don't have an internal regulator.

U6 appears to be reserved for a PSU supervisor IC that issues a reset if the supply falls below a certain threshold. I suspect that the SM2232T may have its own internal supervisor logic.

_________________
A backup a day keeps DR away.

It would take me less than an hour to trace the circuit and come up with a diagram of my own.

The NAND flash pinout appears to be standard:

K9GAG08U0E-SCB0, Samsung, NAND Flash, 2.7V - 3.6V, 16Gbit, 8KB + 436B page size:
http://rln.nnov.ru/uploads/files/k9gag08u0e.pdf

The CF connector pinout is also standard.

I have also found a circuit diagram that might help (even though the controller pinout appears to differ significantly).

_________________
A backup a day keeps DR away.

Wrong capacity almost certainly means controller firmware damage, I would think a very slight chance that any failed component could exhibit this behaviour, and as Fzabkar says, not much to really check. As Sasha says, chip off recovery is the solution here, if you don't have a NAND chip reader, then you might need to either get one or outsource. For someone with the tools, a very run of the mill recovery, as long as the chip read is good and the controller didn't go "berserk"

Thank you for the reply guys, waiting for my soft center hw& sw

Good luck, and if you need help with anything if you haven't done this kind of work before, just ask.

BTW, advise read the manual pages, and if you are going to need support, pay attention to:
chip numbers (and marking the photo correctly)
key in profile
good pictures
upload FE folder with the dumps

for no delays

in the meantime, go to the library, find similar devices and try and get familiar with possible similar cases. It wont make sence now, but when you get the kit you wont be so green and waste time

Quick question, I got a part to attempt to xplant the chips, the flash and MCU are the same but the PCB has a different layout, do you guys think the xplant to the part's PCB will work? the difference are the bad card U3 and U1 are populated, on the parts are U4 and U6.

thank you

I doubt it.

Just wait for the flash extractor to come

I'll help you with it if I can

_________________
PC Image Data Recovery
http://www.pcimage.co.uk

New!! HDD-PCB.COM for all your PCB and donor HDD requirements!

The PCBs appear to be functionally and electrically identical. The differences in the Ux circuit references are irrelevant. The designer could just as easily have chosen any name, eg IC102.

That said, the PCB manufacturing dates differ by 20 weeks (week 04 of 2011 versus week 24 of 2011), so it could be that the flash controllers have some differences in their embedded firmware (is "ST7287.1" a firmware version or a serial number?) that would cause them to interpret the flash data differently. Moreover, you would need to do some circuit tracing to determine the NAND chip order.

BTW, you still haven't determined the nature of the fault. How do you know which chip is bad?

_________________
A backup a day keeps DR away.

I agree with pcimage, wait for FE. IMHO, probably chips are fine, data intact or mostly intact. controller firmware/damage the cause.

The difference in PCB could be quite important, such as a slight timing change or to suit the later revision of the controller.

I would say the date codes of controller are are 1048 and 1128 respectively, I doubt you could find any information anywhere if Silicon Motion simply produced chips this whole time exactly the same, or if there were slight revisions. It is possible the number Fzabkar referred to is a serial or revision, but it is not a firmware code. The firmware code is normally on a sticker on a NAND Chip if it is recorded, never printed onto a controller.

Even if exactly the same, very unlikely for a transplant to work, as the firmware would almost certainly be different, and even if it wasn't, during the process of Envoy getting the device ready with the mass Production tools, the tools have many configuration settings that match to the device/NANDs and I would highly doubt you could use a donor board and controller on the patient NANDS, and transplanting all chips if PCB is not exactly the same is going on a hope and pray.. Also, a controller like that is not a piece of cake to transplant!

The date codes I was referring to are those printed on the PCB.

As for the other numbers, I found a few images:

http://flash-extractor.com/library/SM/S ... a__2x1.jpg
http://www.flash-extractor.com/forum_old/files/cf.jpg
http://www.flash-extractor.com/forum_ol ... g_1319.jpg

SR1442.1 1030 SM2232T AD
SR2262.1 1032 SM2232T AD
SR8153.1 1048 SM2232T AD
SR8154.1 1048 SM2232T AD
ST7287.1 1128 SM2232T AD

It appears that the "ST" number may be a batch code rather than a firmware version. Maybe the "AD" is related in some way to the embedded ROM code???

As for a sticker, that would identify the firmware that is programmed into flash or OTPROM, but it would not reflect the mask ROM version, assuming that's what is inside the controller. IME the mask ROM-ed firmware version is always printed on the IC package by the IC manufacturer, if it is printed at all.

_________________
A backup a day keeps DR away.

Thank you fzabkar, HaQue and pcimage for the replys, I talk to the client he is willing to wait till I get my SC kit

Thank you pcimage, I will let you know, I have used SC but is been about 4 years I dont do any CF recoveries....

sasha, is "double-crystal" a way of saying 2 banks? I haven't heard that term before..



I agree it is likely a batch code. The AD could be related to the ROM, but I think more likely a revision of the chip, or a code to specify what features it has. Thanks a lot for info about the masked ROM, I know a little about it but never worked with it at low level. It isn't readable easily, meaning extractable? It would be fun to analyse.

The customer of Silicon Motion get the controllers in a state that requires just firmware from the mass production tools. They get very little instruction, with quite a bit in their "manual" listed as "this setting will be told to you by silicon motion". It would be great to get some details on the controller further what is available at places like flashboot but I doubt that will ever happen.
Hopefully a few things I am working on will provide a few answers. But for Data Recovery, probably none of it is needed.. like you don't need to know the make of printing press to put a torn up magazine back together. just work of the pieces and fit back together, knowing a rough probable structure and prior experience.

I think a discussion on the electronics is valuable. If you are research, it can make it a lot easier when you are hooking up scopes or LA's to know what you might expect, where to actually probe and notice anything wrong(or right as well so you know not to pursue that line of investigation)

The term "ROM" is used ambiguously these days, so I can never be certain whether it refers to genuine ROM or whether it refers to OTPROM or flash. The Silicon Motion datasheets use the term "ROM" in a way that would imply that the code is preprogrammed, in which case the customer's firmware settings would have to be stored in external memory, but I'm not certain of this. You would probably know from your NAND dumps where this data goes.

My experience with mask ROM-ed controllers is rather outdated, and I haven't really delved into modern CPUs a great deal. In the early days Intel's 8051 8-bit microcontroller was very popular. In fact it is still around today, although as a core rather than as a discrete processor. The original chip was available in several forms, including ROM-less, mask ROM, and EPROM. There was also a version which had a BASIC interpreter in 8K ROM.

As for whether you could dump the masked ROM contents, that was indeed possible in some cases. In fact there were several occasions when I needed to do this (the chip was faulty but not totally dead), after which I programmed the EPROM version of the same uC. Many of today's MCUs have JTAG pins or UART pins to access the internal memory. Some MCUs have security "fuses" which prevent access to the internal memory once it has been programmed (I had a swimming pool controller which I couldn't repair for this reason). ISTM that if you had some way of confirming whether two controllers had the same firmware, then it would make data recovery a lot simpler. That is, it would be much easier to transplant a chip rather than to assemble NAND dumps, especially in those cases where encryption was involved. It surprises me that this the kind of information is not present in the documentation for tools such as Flash Extractor, or is it?

_________________
A backup a day keeps DR away.

FE Documentation is very bare. My understanding is that if you cant easily get a result with the current software, you upload your dumps to them(I believe 1 or a few guys only) and they(he?) will work it out(or not) and tell you the recovery parameters, and add it to the tool for other people to use. It is fairly uncommon to find many devices with the exact same config. Sergey himself has said, and I quote "FE is not a research tool" when asked to implement certain features. He works on easiest cases first, and there is some technology not supported due to no details being available. I know of no case where any manufacturer of controllers offer ANY information that would help in DR, aside from (I am guessing) leaked Mass Production tools and their scarce docs.

The following should be noted:
DR tools work by reassembling the data "image" so in basic terms, you might direct the DR software of whatever solution to say:

-take blocks (231, 333, 126, 45, 1....n) and apply a pre-discovered "layout".. info about ECC, Page parameters, basically parsing the Service Area.
-Invert the data (and reorder the data)
-join every 4 block pairs together (and reorder the data)
-join each page with the next page (and reorder the data)
- now assemble that into an image and say that each block is now 0x40800 in size, and along with some other parameters build an image.
-cut some blocks of the image out in a certain pattern.
-This is your final image.

The note is that none of these operations correspond with anything vaguely present in the tools vendors use to program the firmware, or setup the devices for end users. Nowhere does a vendor, rebrander say "I want the data to be mixed with block pair" for example. And as a mirror to the DR Guy, most of the parameters the MP tools use have no bearing on recovery.

We simply have no way of know what is "inside" any controller. I played with finding JTAG on a Sandisk drive. My JTAGulator identified some possible JTAG points but I couldn't get any results with any software.

NAND memory manufacturers do provide some programming tools to end users (Flash memory manufacturers or..) to program some of the NAND parameters such as : how invalid blocks are treated (skipped or mapped to a reserve area), spare area arrangement scheme, ECC used, where meta data is placed ( Bad block table, MAC address etc) etc. This means that those parameters have to be stored somewhere in a programmable memory ( in the NAND or inside the MCU).

Check this:

https://www.elnec.com/sw/an_elnec_nand_schemes.pdf

Thanks to HaQue and Matiw for the clarification. ISTM that the best approach might be to backup the NANDs and attempt a standard recovery. If you strike trouble, then try a transplant and hope for the best.

_________________
A backup a day keeps DR away.

Hey Fzabkar, I wouldn't call it clarification 100% but really my understanding of it.

not to take anything away from the usefulness of the doc, I have read it over the last few years a few times, it is a good overview. That Elnec doc is pretty good for a rudimentary understanding of NAND, though IMHO weighted heavily on the NAND flash you might find containing an OS of a consumer device, say a home router, and not so much flash storage for flash drives or cards. It is also from 2009, and like most flash docs, specify things like page sizes and block sizes that are "common" or most often numbers that are pretty much obsolete. Pretty much no detail into exact algorithms, no source code, no whitepapers for exact implementations exist for the ones we(I) need and these would be not so much NAND docs, but controller manufacturers docs I would be looking for.
I think this topic has drifted so far from original that maybe when more info on what we are talking about shows up we should resume it in the research and dev forum.