I assume this topic "for posterity" because I went through the above-mentioned procedure with SUCCESSFUL and brought back to life the SP S55 120GB SATA III SSD.
I would like to encourage discussion and exchange of knowledge (if there are other methods, please post them here).
First off, what drives are affected by this issue?
- Goodram CX100, CX200, CX300, CX400, S400U, IRDM, Iridium,
- Silicon Power S55, Slim S500, Slim S55, Slim S60,
- Kingston A400, SSDNow UV300, SSDNow KC400, HyperX Savage, SMSM15S3,
- Plextor m6V,
I am afraid that the list is incomplete, hence the request for suggestions for additions.
Description of the problem: the SSD based on the Phison PS3111 controller is detected in the BIOS (and in the Windows device manager) as SATAFIRM S11. You can see the capacity of the disk, but it is UNININITIALIZED, cannot be initialized, no data is visible.
Why is this happening? The Phison PS3111 controller itself is not a particularly sensational design, but it is not the problem here. To be more precise: it's not the one that crashes. The visible effect is the result of the controller blocking access to memory cells and it is its defensive reaction associated with memory chip damage NAND. So the problem is poor quality memory sticks *.
* - premature application. I found info that NAND degradation is one of the possible causes. There are more reasons for this, such as: a broken address translator or more generally: damage to the drive's INTERNAL SOFTWARE.
The search for a solution to the problem led me to the following conclusions:
- if you want to recover data from such a disk, you are in the dark.... because the only method found was to use professional tools, e.g. PC 3000 UDMA from Ace Lab and companies specializing in Data Recovery have such.
I do not post links because I do not want to advertise Data Recovery companies that have such a tool, but asking uncle google about the SATAFIRM S11 problem will confirm what I briefly wrote above.
- if you want to bring an SSD to life i you don't care about the data there's a method for that. I will describe it below.
REMEMBER !
1. THE PROCEDURE BELOW WILL ERASE THE DATA CONTAINED ON THE MEDIA CARD Irretrievably
2. THE CONTROLLER BLOCKED ACCESS TO THE MEMORY CELLS FOR A SPECIFIC REASON - PROBABLY DUE TO DAMAGE TO THE MEMORY BLOCKS, although this is not the only possible reason. The fact that the disk comes to life does not mean that it will be 100% functional (it may or may not be). It will work, maybe for a while, maybe a little longer. I wouldn't trust him implicitly. I'M TESTING THIS ISSUE: how durable is the repair...
3. IF YOUR DRIVE IS UNDER WARRANTY, GIVE IT FOR A WARRANTY REPLACEMENT . YOU WILL GET A NEW DISK, WITH THE MEMORY CELLS IN A MUCH BETTER CONDITION THAN WHAT YOU HAVE IN THE "FAILED" DISK. If there is no warranty on the drive, you can have fun and only in this case use this guide.
PROCEDURE:
VERSION 1: repairS11 tool (there is also a repairS10 Phison PS3110 version). We connect the drive to SATA, run it with ADMINISTRATOR privileges, after executing the script, we turn off the computer (it is important to cut off POWER from the SSD) and turn it on again.
NOTE 1: ! DATA-DESTRUCTIVE PROCEDURE ! These disks have dynamic memory allocation. Allocation data is erased so forget about any data recovery after doing it.
NOTE 2: for me, the above-mentioned tool supposedly executed the script correctly, but it did not work. After restarting the computer, the drive showed up as SATAFIRM S11 again. Looking through the opinions of users, I conclude that the above-mentioned tool worked on the Kingston A400, so I wouldn't cross it out completely and would not consider it ineffective just because it couldn't handle the Silicon Power S55. I described it first because it is SAFER and EASIER TO USE. Method 2 (below) is a game of forced flashing of the SSD and a mistake in the firmware version ends the game, i.e.: it bricks the disc in a way that I have no cure for *.
* - well, not quite... Experience has shown that drives with an incorrect firmware version can be put into a mode in which they show up with a capacity of 2MB / 8MB / 10MB (small) and despite the incorrect firmware, the controller becomes visible to flasher. The above is obtained by shorting soldering pads under jumpers or soldering pads of a certain resistor (which PCB is in a different place and with a different designation).
VERSION 2: reload FIRMWARE forcibly. To approach the topic, it is necessary to know the firmware version of your drive. This can be done, for example, with the free tool CrystalDiskInfo. Despite identifying the drive as SATAFIRM S11, I saw the SBFM21W1 version for this SP S55 120GB.
Interestingly, there is no such firmware version officially, i.e. the closest one is SBFM21.1.
An interesting observation: some of the drive's SMART parameters look like total crap and have nothing to do with its actual history. Is it a sign of "running apart" of data? Could this be the reason for the controller being blocked?
ATTENTION! THE LETTERS AND THE FIRST TWO NUMBERS ARE IMPORTANT (the ones to the dot) FIRMWARE VERSION . THE NEW FIRMWARE MUST BE COMPATIBLE WITH THEM, otherwise you will brick the drive. To write it more clearly: do not upload the SBFM51.1 firmware to the drive with the current SBFM21.1 version because it will not work. It will be game over. Do not upload SBFA10.3 or anything "on the stick" because it will be a brick. The discrepancy may be after the period, never before.
Where to get FIRMWARE? On usbdev.ru guysfrom across the eastern border did a good job and collected in one package disk firmware for PS3111.
I post here link to download the collective package. The guys did a good job of describing the markings. I will not copy their work. WORTH LOOKING, READING. Use a translator if you have a problem with Cyrillic. Of course, the package must be downloaded and unpacked (RAR).
When, as part of the fight with the disk, I tried (still a bit lost) to use the Firmware Upgrade Tool (provided by the disk manufacturer and downloaded from the electrode from one of the posts regarding this problem) for SP S55 with the SBFM21.2 version (upgrading the firmware from 21.1 to 21.2 ), the tool threw an incompatibility error with the current firmware version.
Could the disk in the locked state controller modify this parameter, thus preventing the use of the tool? Or maybe the tool does not upload the full firmware but performs a differential upgrade? Either way, be prepared for the fact that the factory tool from the disk manufacturer may not work and the numbering of the firmware may change cosmetically when the disk goes into the state of blocking access to memory. On the Silicon Power S55 it was just like that.
In the package from the guys from usbdev.ru I found the SBFM21.1 firmware, which is dedicated to my drive - so there was something to upload. Now comes the question of the tool. I have attached the tool below: s11-flasher
How to use it?
1. Unpack
2. copy the previously identified correct firmware to the application directory, rename it to fw.bin
3. on "low privileges" (i.e. NOT ADMIN) run the s11-flasher2-micron file. The above script will create the fw.exe file that we will need
4. Run fw.exe WITH ADMIN PRIVILEGES
A window will appear very similar to the factory firmware flasher BUT unlike the factory flasher THERE ARE NO PROTECTIONS in terms of firmware version incompatibility. Simply, after pressing UPGRADE, it uploads the previously copied firmware without going into whether it is good or bad.
OF COURSE, YOU PRESS THE UPGRADE BUTTON AT YOUR OWN RISK. It could end up in a brick, which I honestly warned you about.
In my case, the firmware upload (SBFM21.1 to the disk, which showed up as SBFM21W1) was successful. After shutting down the computer (power cycle) and turning it back on, I got a working SSD with a clean SMART. I paid special attention to it, because I was very curious about the scale of destruction and damage caused by the controller cutting off access to memory cells.
After registering SMART, I decided to play around with disk diagnostics to get an idea of the extent of the problem that caused the controller to enter the blocking state.
First test: initialization, partitioning, chkdsk x: /f /r - it was clean
Second test: HD TUNE scan - it was clean
Third test: I used HIREN's boot cd - LINUX environment and performed ENHANCED SECURE ERASE of the disk, knowing that it is performed at the SSD controller level and touches every memory cell. So if there is something wrong with the memory cells, one of the SMART parameters (most without description) should clearly increase. In addition to the number of disk startups, only one parameter has grown: by 1. I concludebecause it could have been a (not described) parameter responsible for something like wear-leveling, i.e. the number of records in all cells. I also suggest you to perform the above-mentioned in case of success - at least there will be some information whether / in how bad the actual condition of the disk is and whether it is worth spending more time on it at all.
Using the factory tool from SP I upgraded the firmware from 21.1 to 21.2. At the moment everything works.
ATTACHMENTS:
I would like to encourage discussion and exchange of knowledge (if there are other methods, please post them here).
First off, what drives are affected by this issue?
- Goodram CX100, CX200, CX300, CX400, S400U, IRDM, Iridium,
- Silicon Power S55, Slim S500, Slim S55, Slim S60,
- Kingston A400, SSDNow UV300, SSDNow KC400, HyperX Savage, SMSM15S3,
- Plextor m6V,
I am afraid that the list is incomplete, hence the request for suggestions for additions.
Description of the problem: the SSD based on the Phison PS3111 controller is detected in the BIOS (and in the Windows device manager) as SATAFIRM S11. You can see the capacity of the disk, but it is UNININITIALIZED, cannot be initialized, no data is visible.
Why is this happening? The Phison PS3111 controller itself is not a particularly sensational design, but it is not the problem here. To be more precise: it's not the one that crashes. The visible effect is the result of the controller blocking access to memory cells and it is its defensive reaction associated with memory chip damage NAND. So the problem is poor quality memory sticks *.
* - premature application. I found info that NAND degradation is one of the possible causes. There are more reasons for this, such as: a broken address translator or more generally: damage to the drive's INTERNAL SOFTWARE.
The search for a solution to the problem led me to the following conclusions:
- if you want to recover data from such a disk, you are in the dark.... because the only method found was to use professional tools, e.g. PC 3000 UDMA from Ace Lab and companies specializing in Data Recovery have such.
I do not post links because I do not want to advertise Data Recovery companies that have such a tool, but asking uncle google about the SATAFIRM S11 problem will confirm what I briefly wrote above.
- if you want to bring an SSD to life i you don't care about the data there's a method for that. I will describe it below.
REMEMBER !
1. THE PROCEDURE BELOW WILL ERASE THE DATA CONTAINED ON THE MEDIA CARD Irretrievably
2. THE CONTROLLER BLOCKED ACCESS TO THE MEMORY CELLS FOR A SPECIFIC REASON - PROBABLY DUE TO DAMAGE TO THE MEMORY BLOCKS, although this is not the only possible reason. The fact that the disk comes to life does not mean that it will be 100% functional (it may or may not be). It will work, maybe for a while, maybe a little longer. I wouldn't trust him implicitly. I'M TESTING THIS ISSUE: how durable is the repair...
3. IF YOUR DRIVE IS UNDER WARRANTY, GIVE IT FOR A WARRANTY REPLACEMENT . YOU WILL GET A NEW DISK, WITH THE MEMORY CELLS IN A MUCH BETTER CONDITION THAN WHAT YOU HAVE IN THE "FAILED" DISK. If there is no warranty on the drive, you can have fun and only in this case use this guide.
PROCEDURE:
VERSION 1: repairS11 tool (there is also a repairS10 Phison PS3110 version). We connect the drive to SATA, run it with ADMINISTRATOR privileges, after executing the script, we turn off the computer (it is important to cut off POWER from the SSD) and turn it on again.
NOTE 1: ! DATA-DESTRUCTIVE PROCEDURE ! These disks have dynamic memory allocation. Allocation data is erased so forget about any data recovery after doing it.
NOTE 2: for me, the above-mentioned tool supposedly executed the script correctly, but it did not work. After restarting the computer, the drive showed up as SATAFIRM S11 again. Looking through the opinions of users, I conclude that the above-mentioned tool worked on the Kingston A400, so I wouldn't cross it out completely and would not consider it ineffective just because it couldn't handle the Silicon Power S55. I described it first because it is SAFER and EASIER TO USE. Method 2 (below) is a game of forced flashing of the SSD and a mistake in the firmware version ends the game, i.e.: it bricks the disc in a way that I have no cure for *.
* - well, not quite... Experience has shown that drives with an incorrect firmware version can be put into a mode in which they show up with a capacity of 2MB / 8MB / 10MB (small) and despite the incorrect firmware, the controller becomes visible to flasher. The above is obtained by shorting soldering pads under jumpers or soldering pads of a certain resistor (which PCB is in a different place and with a different designation).
VERSION 2: reload FIRMWARE forcibly. To approach the topic, it is necessary to know the firmware version of your drive. This can be done, for example, with the free tool CrystalDiskInfo. Despite identifying the drive as SATAFIRM S11, I saw the SBFM21W1 version for this SP S55 120GB.
Interestingly, there is no such firmware version officially, i.e. the closest one is SBFM21.1.
An interesting observation: some of the drive's SMART parameters look like total crap and have nothing to do with its actual history. Is it a sign of "running apart" of data? Could this be the reason for the controller being blocked?
ATTENTION! THE LETTERS AND THE FIRST TWO NUMBERS ARE IMPORTANT (the ones to the dot) FIRMWARE VERSION . THE NEW FIRMWARE MUST BE COMPATIBLE WITH THEM, otherwise you will brick the drive. To write it more clearly: do not upload the SBFM51.1 firmware to the drive with the current SBFM21.1 version because it will not work. It will be game over. Do not upload SBFA10.3 or anything "on the stick" because it will be a brick. The discrepancy may be after the period, never before.
Where to get FIRMWARE? On usbdev.ru guysfrom across the eastern border did a good job and collected in one package disk firmware for PS3111.
I post here link to download the collective package. The guys did a good job of describing the markings. I will not copy their work. WORTH LOOKING, READING. Use a translator if you have a problem with Cyrillic. Of course, the package must be downloaded and unpacked (RAR).
When, as part of the fight with the disk, I tried (still a bit lost) to use the Firmware Upgrade Tool (provided by the disk manufacturer and downloaded from the electrode from one of the posts regarding this problem) for SP S55 with the SBFM21.2 version (upgrading the firmware from 21.1 to 21.2 ), the tool threw an incompatibility error with the current firmware version.
Could the disk in the locked state controller modify this parameter, thus preventing the use of the tool? Or maybe the tool does not upload the full firmware but performs a differential upgrade? Either way, be prepared for the fact that the factory tool from the disk manufacturer may not work and the numbering of the firmware may change cosmetically when the disk goes into the state of blocking access to memory. On the Silicon Power S55 it was just like that.
In the package from the guys from usbdev.ru I found the SBFM21.1 firmware, which is dedicated to my drive - so there was something to upload. Now comes the question of the tool. I have attached the tool below: s11-flasher
How to use it?
1. Unpack
2. copy the previously identified correct firmware to the application directory, rename it to fw.bin
3. on "low privileges" (i.e. NOT ADMIN) run the s11-flasher2-micron file. The above script will create the fw.exe file that we will need
4. Run fw.exe WITH ADMIN PRIVILEGES
A window will appear very similar to the factory firmware flasher BUT unlike the factory flasher THERE ARE NO PROTECTIONS in terms of firmware version incompatibility. Simply, after pressing UPGRADE, it uploads the previously copied firmware without going into whether it is good or bad.
OF COURSE, YOU PRESS THE UPGRADE BUTTON AT YOUR OWN RISK. It could end up in a brick, which I honestly warned you about.
In my case, the firmware upload (SBFM21.1 to the disk, which showed up as SBFM21W1) was successful. After shutting down the computer (power cycle) and turning it back on, I got a working SSD with a clean SMART. I paid special attention to it, because I was very curious about the scale of destruction and damage caused by the controller cutting off access to memory cells.
After registering SMART, I decided to play around with disk diagnostics to get an idea of the extent of the problem that caused the controller to enter the blocking state.
First test: initialization, partitioning, chkdsk x: /f /r - it was clean
Second test: HD TUNE scan - it was clean
Third test: I used HIREN's boot cd - LINUX environment and performed ENHANCED SECURE ERASE of the disk, knowing that it is performed at the SSD controller level and touches every memory cell. So if there is something wrong with the memory cells, one of the SMART parameters (most without description) should clearly increase. In addition to the number of disk startups, only one parameter has grown: by 1. I concludebecause it could have been a (not described) parameter responsible for something like wear-leveling, i.e. the number of records in all cells. I also suggest you to perform the above-mentioned in case of success - at least there will be some information whether / in how bad the actual condition of the disk is and whether it is worth spending more time on it at all.
Using the factory tool from SP I upgraded the firmware from 21.1 to 21.2. At the moment everything works.
ATTACHMENTS:
