Patriot BURST 240GB, SATAFIRM S11 Data Recovery: Phison S11 Repair & Flash ID Info

Hello everyone
I have a big problem with the disk as in the topic. I tried various tools, e.g .: Phison S11 repair From this side:
http://vlo.name:3000/ssdtool/

tool Phison flash id reads from disk this:

Model: SATAFIRM S11
Fw: SBFM21W1
Size: 228936 MB
P / N: 511-170717128, SBSM21.0
S11fw: SBFM21.1, 2017 Jun14
Original Model: Patriot Burst
Bank00: 0x2c, 0xc4,0xe5,0x32,0xaa, 0x4,0x0,0x0 - Micron 32L (L06B) MLC 512Gb / CE 256Gb / die
Bank02: 0x2c, 0xc4,0xe5,0x32,0xaa, 0x4,0x0,0x0 - Micron 32L (L06B) MLC 512Gb / CE 256Gb / die
Bank08: 0x2c, 0xc4,0xe5,0x32,0xaa, 0x4,0x0,0x0 - Micron 32L (L06B) MLC 512Gb / CE 256Gb / die
Bank10: 0x2c, 0xc4,0xe5,0x32,0xaa, 0x4,0x0,0x0 - Micron 32L (L06B) MLC 512Gb / CE 256Gb / die
Controller: PS3111
Flash CE: 4
Flash Channel: 2
Dram Size, MB: 32
Flash CE Mask: [+ - + ----- + - + -----]
Flash Mode / Clk: 5/7 (Set 5/7)
Block per Die: 2192
Block per CE: 4384
Page per Block: 1024
SLC Cache: Default
MaxBBPerPlane: 70
ONFI [A7]: MICRON MT29F2T08CUCBBM4 [12E9]
Page size: 18592 (16384 + 2208)
Page / Block: 1024
Plane: 2

Defects All (per plane) Early Later
Bank00: 28 (9.13) 28 (9.13) 0 (0.0)
Bank02: 20 (5.5) 20 (5.5) 0 (0.0)
Bank 08: 27 (9.6) 27 (9.6) 0 (0.0)
Bank10: 19 (7.5) 19 (7.5) 0 (0.0)
Total: 213 213 0

Early defect list
Bank00: 96 97 98 99 100 101 102 103 104 105 106 107 108 109 352 353 354 355 609 611 1931 2000 4192 4193 4194 4195 4196 4197 4198 4200 4201 4202 4204 4205 4448 4449 4452 4453 4493 4704 4705 4708 4709 4993 5001 5217 5615 5729 6027 6096
Bank02: 96 97 98 99 100 101 102 103 104 105 106 107 108 109 352 353 355 356 357 608 609 612 896 897 900 904 1120 1128 1376 1636 1931 2000 4192 4193 4194 4195 4196 4197 4198 4199 4200 4201 4202 4203 4204 4205 4449 4451 4707 5234 6027 6096
Bank08: 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 352 353 354 356 358 608 612 896 1638 1931 2000 4192 4193 4194 4195 4196 4197 4198 4199 4200 4201 4202 4203 4204 4205 4207 4227 4448 4449 4450 4451 4452 4705 4706 4708 4996 6027 6096
Bank10: 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 352 353 354 355 356 357 358 608 609 611 612 613 614 757 896 901 904 909 1021 1637 1931 2000 4192 4193 4194 4195 4196 4197 4198 4200 4201 4202 4203 4204 4205 4448 4449 4452 4475 6027 6096

Later defect list

Attr Tresh Flags ValId WrstId RawId Description

I tried reading that the chances of getting to the data are flashing the firmware, I tried, for example, various toolboxes are phison - unfortunately or I get info that it is not MLC solution or e.g. upgrader FW SBFM21_1 (ea11) throws a prompt:

After ISP Jump, Set AP-Key Failed !!

Interestingly, some toolboxes show the whole green circle 240GB in the status and some show some 113GB in red, which is as if they saw the data there.

will anyone give me a hint?

thanks in advance

Where did you read this information?
Uploading the software involves reinitializing the memory chip and resetting the content.
If the procedure has been initialized (despite throwing an error), the data is already over.

@ Łukasz_W what I can try to do - thanks for your interest

Thread.
You need to contact the company that has a solution for this controller and knows what to do in order not to permanently lose the content, as above.
You need to load the replacement software and rebuild the translator. Successful recovery depends on the condition of your memory.

and this replacement software is more precisely?

https://blog.acelaboratory.com/pc-3000-ssd-phison-utility.html
The key question - have you been updating the firmware?

You need to recharge the microcode that allows you to read the part of the firmware that is in the NANDs and contains information unique for a given carrier, such as translation tables, defect lists, on the basis of which LBA addresses can be assigned to specific physical addresses. This controller uses dynamic randomization, so desoldering the circuits and retrieving data from the read binary using mathematical methods supported by the analysis of logical structure elements is not an option. In short - if you plan to force the medium to work, forget about the data. Someone who advised you to flash the firmware has no idea about data recovery, and the message you posted justifies the fear that you might have managed to destroy the content, because you obviously had communication with NANDs.

@ Lukasz_W
I started flash but whether it was an upgrader or from the toolbox, I always had a negative message - the disk state does not change in any way (I think) .. in the sense that all the time SATAFIRM S11 and all the time FW read then via Phison flash id is the same, i.e. SBFM21W1, and some versions of the toolbox in the% capacity ball still see 113GB as if data / occupancy .. I have the impression that all these operations simply did not contribute anything because it seems or they did not come to an end correctly with upgrades (5%) and errors .. and toolboxes and messages that it will not perform the operation and that's it ..

@kaleron
Is what you wrote when it comes to performing microcode recharge that allows you to read this part of the firmware located in NANDs only through (as my colleague @ Łukasz_W suggests) - PC-3000 and this equipment?

thanks again for your interest

The fact that the entire process has failed does not mean that erasing the memory contents could not have succeeded even partially. The message issued by the carrier indicates that access to NANDs has been cut off, which does not mean that low-level programs that receive this access, according to the message you posted, could not perform any operations. And these are operations that are irreversibly destructive to data. And these programs do not analyze the content in terms of logical structures at all, so do not interpret a message with a visible 113 GB as information about used space in terms of logical structures. Programs of this type often show nonsense during operation and only at the end restore access to the full LBA addressing. If you've done 5% of the operation, that's enough to make you tremble for your data.
Yes - the easiest way to recharge this microcode is to use a PC-3000 with a software extension for SSD. This is not the only way, but the ATA commands you would have to use when doing it manually are not documented. It is really bad that you tried to fix this media by flashing. Unfortunately, there is no shortage of such irresponsible advice, and it is difficult to obtain reliable knowledge.

As your colleague Kaleron says, you can probably say goodbye to the contents of the disk or most of it.

hmm .. well ..
the topic seems to be closed ..

Added after 39 [minutes]:

and the fundamental question about the cause - what is the cause of the "run-up" of the FW?

Weak memories, smaller and smaller transistors, packing more and more bits into the transistor = the need to distinguish more and more charge levels, manufacturing defects - all this translates into an increasing number of bot errors. There comes a moment when the ECC codes are not enough, something crashes and the problem is ready.

thanks again