[Help] Inconsistent dumps from CH341A programmer

As the title states, I have a CH341A programmer (green one/CH341A programmer v1.7) which seems to work just fine, but there’s a problem when it comes to reading my laptop’s BIOS chip (in-system progrramming, battery disconnected from laptop) and it’s how the data that is read from the programmer is inconsistent, in the sense that each read operation, once finished will have some sort of variability and when opening the dumps in UEFITool, one of GUIDs (which is for a compressed LZMA volume) seems to be corrupted as well, not all of the dumps got this far though (some were even more corrupted)

I haven’t been able to get a single dump that has the compressed LZMA volume readable by UEFITool and that seems to be the furthest I can go.

Laptop is an HP Victus 15-fb0102la with a Winbond W25R128JW, which flashrom recognizes as a W25Q128 and NeoProgrammer doesn’t identify which one it is exactly but gives two options, those being the W25Q128FW and the W25Q128JW-xM.

According to Winbond’s own site, the W25R128JW uses an operating voltage of 1.8V, which was configured on the programmer’s voltage switch but it was still getting inconsistent reads.

Not sure if I’m supposed to read with the battery connected or what, but I can safely say that the clip had a strong/firm connection to the SPI flash.

Note: I couldn’t upload the dumps in a ZIP file, will try uploading later.

Couldn’t upload the dumps here (it would tell me to try again later and when I did, it wouldn’t work) so I uploaded them to Google Drive.

And this is the link to the latest BIOS file (taken from HP’s EFI updater, original file name was “08A3C.bin”):

There are options regarding stby battery / main battery (careful), last step would be desoldering.

Otherwise not much to add from distance.

I think I already mentioned me disconnecting the battery during the whole process, after plugging it back, putting the laptop’s lower part of the chassis back on and turning it on, my BIOS settings were reset (CMOS reset triggered from battery disconnection).

So in short, when I was doing in-system programming, the battery was disconnected and yet the dumps were inconsistent.

Then probably your last option is to desolder the IC from the PCB and observe the results.

Well I don’t think I’ll get that far considering I lack the necessary tools for desoldering and resoldering (while also lacking the necessary knowledge and experience to pull it off).

I hoped that it wouldn’t have ended this way but oh well I guess I got a CH341A programmer for nothing if I can’t do in-system programming.