Recently when I was unplugging my Sandisk Ultra flash drive from a computer that was stuck in the middle of a BIOS boot which I set to boot into this flash drive, I suppose that I had made it gone wrong in an unwelcomed way.
The drive had been marked “Write Protected”, as though someone put on a lock on the drive. With a bit of luck I attempted to recover this flash drive and got it into a healthy state. The following paragraph is what I posted on a social media:
Finally get to fix my flash drive ‘s write protection with a firmware upgrade. Drive bricked when going through the sixth attempt while the first five just thrown me errors. Connected pin #13 and #15 to short the jumpers of the Phison MLC controller. After that I was able to make a flash to unblock the device and rename it. All fixed alas, just hope it won’ t be running into problems anymore...... : P
This post would feature on a hand-by-hand tutorial, which only apply to the 2015 models of Sandisk Ultra CZ48. The product number should be something like this:
BL150624844B. While other editions might not be guranteed full probability, they might be fixed in similar ways.
For details, enter the post for more information.
Therefore, if you are not aware of the consequences of these actions, please do not use it in actual practice; If you are aware of them, please make sure you do not care about the following potential defects:
- Decreased stability and reliability
- Indefinite loss of read/write speed
- Warranty of device void
- Potential loss of important data
In case of awareness, do not consult the author for further assistance or blame the author for giving allegedly fake operations. I only expose my steps, and do not provide gurantee that you will finish these operations without problems. Restating that if you are aware of the consequences please leave immediately!
Typically, a software brick of this drive would be easy to fix. Common problems include:
- Hardware-set write protections (The one I experienced)
- Incorrect report of partition sizes
- Frequent loss, change or lack of change of data
Rewriting the firmware to the controller of the flash drive may solve some of these problems, but detailed consequences except that of the first are not tested, and I bet nobody wish to.
During my testing of various versions of softwares, including the frequent bricking and unbricking procedures, I gathered a large amount of utilities, of which only a countable few are useful, lest the others are quite damaging. I shall provide a list of those, in hope that some of you may find them on the Internet.
After a long time of testing and dangerous operations, I retrieved a list of required applications and am ready to provide it to you:
|Module Name||Actual Values|
|GetInfo. exe||3. 8. 4. 2|
|MPall. exe||3. 63. 00|
|Burner File||BN03V114M. BIN|
|Firmware File||FW03FF01V10810M. BIN|
Without any luck, I tried a few other combinations, all resulting in bricking the flash drive, luckily not permanently (the solutions will be mentioned later). These are a few screenshots of the actions before the final success:
Do not follow these pictures as they will result in potential bricks. Maybe they will raise ‘unspecified error’ s, which means that they cannot be written to the flash drive. Potential causes are:
- Mismatch between chip architecture and firmware architecture ((Bricks)
- Flash utility version mismatch
- ROM actively refused to accept the firmware (rarely seen)
For the first one, do not attempt to enforce burn process or it will end in bricked device. For the second version, simply switch to version 3. 63. 00 which is one of the most common versions of these utilities. For the third problem, simply refer to the brick solution.
In Case of Bricks
When we need to deal with a bricked device and there is no way into the device through software, we need to enter it through hardware, which is why we need to penetrate its shell and open it up.
The way of doing this, is simple. There are two switches / blockers on either side of the slider of CZ48. Use two plastic plates (must be thin enough) to block these blockers in order to stop them from blocking the extraction of the slider. After removing the slider, the chip can be easily seen.
Warning: The following section applies to chip Phison 2215-03 only. Users with other chips must check their jumper configurations carefully before actually applying this operation. Misbehavior might cause burning of the controller, leaving the device in a hardware brick state, unfixable forever.
Viewing from the text aligned aright, short the Pin #13 and Pin #25 and retain this state until it connects to the computer. If it is successfully shorted, then the red light on the flash drive should be always on.
Pin #13 is the rightest pin on the top edge, #25 is the lowest pin on the right edge. Connect them with tools to gain access.
After that, an unknown device would show up on the computer, and MPall would be able to burn the firmware to the device again. If you have already shorted the controller, feel free to remove the shorting cords.
You can rename your flash drive in any way you like, just like the following examples:
Another broken flash drive, which is a 2016 version Sandisk Ultra, uses not Phison 2215-03, instead another unrecognized chip. This led to the fact that it cannot be fixed through hardware, nor could it be fixed through software.
The flash drive, when plugged into the computer, states that it is a 64MB flash drive called “Sandisk Anisha”. Since I had not been able to fix it, no further research was done on it. If you figured out how to fix this, Email me if you like and tell me how I can fix it. I will attribute your contributions.
If you are still aware of these problems that I initially stated, maybe it is time that you abstain from those medieval methods and run a test on the drives.
Verum index sui et falsi.--Karl Marx
It sure would help you know more.