So when trying to flash a lightly modified bios rom to my pe70, I fat-fingered the filename in FPT and accidentally flashed an image that wasn’t created by FPT. This, of course, reset the smi/smm lock value and blocked my ability to flash from windows. Upon restarting the laptop, I was greeted with nothing but lit up keys and a black screen, and about 30 seconds later one of the fans spinning up to near full speed. The usual MSI bad flash behavior.
Since I basically did this same thing back in March, I had a CH341A (black) programmer on hand and attempted to reflash the stock image. With the battery out and the AC adapter disconnected I was having a hell of a time trying to get the chip to even read, let alone wipe and write. Figured out that with the battery in it had a better shot but when you’re trying to nail down what variable is the issue when there are 3-4 different drivers, 15+ (I can upload a zip as proof) programs, and 4 different laptop power setups, you end up trying quite a few different solutions.
While messing with that and dealing with the constant frustration of a crappy test clip that keeps popping off (the tips rounded off) I ended up shorting some of the different bios pins that are adjacent to each other with the CH341A powered on, battery in, and maybe once or twice with the laptop turned on. This I am confident of due to the fact the laptop powered on a couple of times while fighting the test clip, which by my best guess was the ~3.3v the device puts out going somewhere that wasn’t expecting it.
During this time I was constantly trying different programs to get the chip to read and a few of them kinda would recognize the chip but not a single one could fully identify it. When I would select mx25l6406e from the drop-down, I could always wipe the chip but it would always fail the check after. Sometimes it claimed to have finished writing but would fail the verification instantly. I also noticed that any reads of the chip would show garbled/garbage data, like the device ID would be different every time I hit “detect chip”. The best I managed to get was AsProgrammer (I think) identifying the chip as only 4 different IDs that would change upon every check.
Since my clip is literal garbage, I’ve ordered another CH341A programmer set (same price as the clip on its own) but while I am waiting on that, I figured I would brace for the worst and ask you guys. Are these constant connection issues/never being able to identify the chip due to the combo of a crap clip, crap software, and cheap programmer. Or did my frustrated flashing technique cook the little guy?
Thankfully a replacement mx25l6406e is like $4-5 and it’s not in the worst place to work on but I’d really really rather avoid that if I can. If I do have to do the replacement, are there any sockets I could purchase so I could just socket it instead? That would make future messing recoveries from idiocy simpler.
System info:
MSI pe70-2qd
E1792IMS.119 bios version
Win 10 pro
mx25l6406e bios chip
Programs tried(2-3 copies of each): CH341A programmer 1.13, v1.18, 1.29, 1.30, 1.31(1.4free), 1.34, 1.1.1.35, AsProgrammer, AsProgrammer 1.4.0, and Colibri 1.0.1.61.
Drivers tried and or currently installed: ch341wdm.inf_amd64, ch341ser.inf_amd64
EDIT: I should state that I am fully aware of what happens if you don’t back up the factory original BIOS before messing with stuff. Totally lost all of my serial info and whatnot back in March during my first go at tinkering with the bios so I’m not super concerned about that happening.
EDIT by Fernando: Thread title shortened (can be changed by the Opener at any time)
Yes, there are SOIC-9 sockets, but I wouldn’t use one in a laptop, at least not without some extra tape to make sure it doesn’t opens up during travel.
I have flashed a lot of BIOS, and I always remove the flash chip, dont like the idea of putting 3.3v into the motherboard, or causing a short and damage it, with a soldering iron, some flux and a tweezer it takes 2 minutes to remove the chip.
Got the new programmer and clip in the mail today. It’s truly amazing how big of a difference that makes in your ability to make contact with the chip.
So far I’ve had 0 luck getting any of the various programs to do anything with this chip. None of them can pull an id and all will encounter some form of error when trying to write.
I also noticed that the new programmer’s read light doesn’t come on when everything is connected where the old one will right away.
It’s starting to look like I either have a fried chip or it is unable to feed enough power in to get a reading which is weird because it worked previously this way.
EDIT: Well I’ve got programmer 1.34 supposedly reading and writing the chip but whenever I read it after writing it has pure garbage data. The last time (just now) it was repeating C2 20 17 for the whole file. It has no problem verifying the garbage data matches the buffer but always fails after writing.
1.34 is kinda detecting the chip and giving me a list of similar chips but isn’t able to erase the chip despite claiming to.
AsProgrammer is picking up ID information however it is constantly changing. However, every 5th time or so It’ll pick up a correct value so I’m hoping that’s a good sign.
EDIT 2: Well, the best I can get is it seeing a chip but its registers are constantly between C2 17 20. All of the dump is filled with this. Would this be from the programmer not being able to deliver enough power? If that is the case do I just disconnect the VCC pin from the motherboard to read/write? Is there a chance that this is due to a conflict with windows?
EDIT 3: I’m starting to think this weird output and behavior is a sign of the chip being toast. Whenever I manage to get a good connection, all that the programmer can see is the C2 20 17 sequence that repeats. The device ID that shows upon refresh is always one of these 3 no matter what programmer and no matter what operating system, c2201717, 2017C2C2, 17C22020. Whenever I do a read I get C2 20 17 repeating until the end of the file. Erasing and writing seems to have no effect.
@extremelyodd - which clip did you get this time? Those cheap ones are a pain for me too always, but I usually eventually get it before giving up and using my PCB Jumper instead.
There should be one bright red LED on when programmer plugged in, then nothing else unless you are reading or writing, possibly during detection too. If a second LED is partially lit at any time, that is a power issue (needs battery or PSU connected, or not), or a bad connection issue.
YOu may need to remove the chip form the board as mentioned above, sometimes this is only option. Windows has nothing to do with any of this.
I would be trying with 1.30 or ASProgrammer, success of those and this chip is documented more than 1.34
If you shorted the chip out, and you see blown or lifted traces, or saw magic smoke, then other areas of the board may be damaged (chip usually survives)
I picked up this piece of hot garbage off of amazon
https://www.amazon.com/gp/product/B07R5LPTYM
It’s basically the same setup as what I had previously purchased. However, I think my clip will last longer now that I know there are tiny teeth that I gotta be super careful with.
When I plug in either programmer I get just the main power indication light. Whenever it’s reading or writing (at least attempting to) the 2nd led flashes.
At this point, I do not believe this has anything to do with the clips connected to the chip as I can reliably repeat what happens and I had the exact same issue with the previous clip. I shall continue to try to clip it on more perfectly but unless I start getting different results, I should be able to say the clip isn’t the issue.
When I get the clip perfectly on, all of the CH341a programs will read the chip’s manufacture id, memory type, and memory capacity as either C2, 20, or 17 in a random order. Once with Colibri it showed a different set of numbers until returning to the C2 series. This is also true for reading the chip, the data is always C2 17 20 repeating. Every single CH341A programmer I’ve tried successfully detects the chip but all of them have the repeating output read issue. That includes both versions of AsProgrammer I can find, all the ch341a programmer versions listed in the OP along with Colibri.
While typing this post I’ve been trying other things and looking stuff up and I discovered what the numbers mean. Those are all the correct numbers for the chip but for whatever reason, those are the ONLY values that can be read from the chip. It’s on page 22
https://www.macronix.com/Lists/Datasheet…4Mb,%20v1.9.pdf
"RES instruction is for reading out the old style of 8-bit Electronic Signature, whose values are shown as “Table 6. ID
Definition”. This is not the same as RDID instruction. It is not recommended to use for new design. For new design,
please use RDID instruction. Even in Deep power-down mode, the RDP and RES are also allowed to be executed,
only except the device is in progress of program/erase/write cycle; there’s no effect on the current program/erase/
write cycle in progress.
The RES instruction is ended by CS# goes high after the ID been read out at least once.
The ID outputs repeatedly if continuously send the additional clock cycles on SCLK while CS# is at low. "
There is no damage to the motherboard to speak of, nothing burnt, charred or otherwise obviously damaged. The pins for the bios chip are starting to look a bit rough from the countless read/write attempts but they are still solid.
After reading the above info I’m thinking I either have a power supply issue as it’s not coming out of the deep power down mode or that it’s fried and won’t come out of deep power down mode.
Well??? That looks to be the same cheap clip, that I assumed you already had first time around?? Ohh, you said that too 
I thought you purchased better clip this time, the way you mentioned it earlier, like a Pomona one or something.
2ND LED should not flash, it should be solid and bright when reading/writing. Did you try with and without main battery attached, and with and without main power cable connected (By itself, and with battery)
Yes, when you get a correct chip ID, then that means it’s connected properly, so that is a good sign here! Please use ASProgrammer 1.40 or 1.41, and use the “Unprotect” function, then try again to dump
I’m not familiar with how these chips work, enough to be able to comment on your findings above, but that may be due to protection, or power being not enough/too much etc.
Some systems, for whatever reason, you have to remove the chip from the board 
@_haru @dsanke @chinobino - Can any of you guys tell us what that means in the above post, from the programmer PDF?
Sounds like CS# is not going high and it should, do you know maybe why it’s not?
I was going to get a Pomona but once I factored how much it would cost to make my own leads and whatnot, I figured I’d be fine with another cheapie. The issue with my old one was not handling it with care and haphazardly connecting it to the chip which would cause it to pop off, damaging the teeth until it finally had no teeth left and no longer grips the chip.
To be entirely honest, I was guessing a bit at what the 2nd led was doing as my easiest to access usb port is just out of the line of view.
Either version of AsProgrammer has the same issue as all of the other programmers: The only data it receives is the ID sequence looping “C2 17 20”.
As an example, I’m going to hit the “Read ID” button in AsProgrammer 5x in 5 seconds and paste the output below.
Current programmer: CH341
ID(9F): F84402(Unknown)
ID(90): 4402(Unknown)
ID(AB): 44(Unknown)
ID(15): F844(Unknown)
Current programmer: CH341
ID(9F): F08805(Unknown)
ID(90): 8805(Unknown)
ID(AB): 88(Unknown)
ID(15): F088(Unknown)
Current programmer: CH341
ID(9F): 84402F(Unknown)
ID(90): 402F(Unknown)
ID(AB): 40(Unknown)
ID(15): 8440(Unknown)
Current programmer: CH341
ID(9F): 22017C(Unknown)
ID(90): 017C(Unknown)
ID(AB): 01(Unknown)
ID(15): 2201(Unknown)
Current programmer: CH341
ID(9F): 8805F0(Unknown)
ID(90): 05F0(Unknown)
ID(AB): 05(Unknown)
ID(15): 8805(Unknown)
Ooh, it added some new numbers to the rotation! When I open the “Edit SREG” feature, every single time I press read, I get the same results as above but with the little checkboxes instead.
All of this is the same with the battery in/out and with the AC adapter in/out. Right now I am able to get these readings without the battery or AC adapter connected.
What I’m not understanding is this output and the programmers lack of reaction to it. Also I’m not understanding why I was able to get this to work in the past, unless I fried the chip but I wouldn’t think it would get any readings if it was fried.
Well the clip itself is what makes the Pomona one better, that’s why I assumed you picked up one of those when you said new one.
Do the “Unprotect” function in ASProgrammer, then try to read again, maybe that will help.
Hopefully someone with more knowledge than I have about how these actually function (ie can interpret the PDF properly) will stop in an answer this for you. No need to continue further for now, the above thing you quoted from PDF is the issue, we need to find why CS# is not going high
You made this work before, on this same exact system and chip? If yes, then there is some issue on your board/BIOS chip I assume, due to the possible shorting you mentioned (Damage is not always visible)
The superiority of the Pomona clip cannot be denied, if I did this more often than the 2nd time in my life I would invest in one and a higher quality programmer.
Sorry for not elaborating further, the edit sreg is a subset of the unprotect function and both only show the same numbers randomly changing every time you hit read or write. Essentially nothing has any effect on the chips programming, it is outputting a constant stream of it’s ID which all of the programmers are accepting as valid data for whatever they are trying to read.
Back in May I basically did the same thing as this time, was tinkering with unlocking all the hidden functional bios menus and after around a half dozen successful flashes, I bricked it. Once I got my CH341A in it took 2 days of messing with everything to get a successful stock flash back on the chip. However, I cannot for the life of me remember if I encountered the chip being stuck in DP, chances are this is a new problem.
After looking into AsProgrammer a bit I found the forum where the developer posts updates and found the github that has all of the source script files for both the old AsProgrammer 1.4.1 and the 2.0.0 test brach. These were a gold mine of info on what everything is doing behind the scenes and from what I can tell the RDP command doesn’t get fired too often.
Seeing that made me realize that the RDP command shouldn’t need to be issued too often. After testing adding one to the top of the block erase script (just above the WREN call), the end results of the erase were the same; It’s not erased and you still only get the ID repeating upon any kind of read.
This process of eliminating items that are fixed without a soldering iron is starting to bum me out. Swapping chips looks to be a bit of a pain in the rear without the proper iron and I’ll be working with my trusty $3 harbor freight fingerburner. Not to mention the fact that you are completely correct in the fact that I might have some unseen serious damage, watching a ton of louis rossmann’s videos has shown me how difficult/impossible some repairs are for the layperson.
EDIT: 11-17-19 There is no need to bump this thread up to the top so I figured I’d add some more info here. After a bit more messing around, it’s really looking like the chip has some internal damage that is causing it to kick into deep power level mode. Either that or the EC is messing with it but after seeing a thread from just last month on flashing a pe70-6qe (same board, updated cpu/gpu) that really shouldn’t be my issue. So I’ve got a 10 pack of MX25L6406EM2I-12G chips on the way and in the meantime I’m going to get some solder braid, pop the current chip off and see if I can’t get it to read/write that way. Either way, the laptop is dead so it can’t hurt.
Finally have enough info to warrant another post.
After spending $10 to get 10x replacement eeproms on ebay, I try the whole “remove the chip and stick it in the programmer” method. Removing the chip was easy enough despite only using a cheap 30w iron and some tweezers. Around this time I started having some flashbacks to when I did this the first time, and remembered reading it was always an issue that I had to repeatedly blind flash until something worked.
Once I got the chip attached to the adapter board and it plugged into the computer my thoughts/fears were confirmed, I was actually writing to the chip with the clip, it just couldn’t show me.
So, I did the whole wipe, check erase, write, verify operation with a fresh copy of the last bios version they released, slapped the chip back into the board, hooked everything back up and pressed the power button.
https://www.youtube.com/watch?v=_asNhzXq72w
Yup, no improvement. The keyboard lights up (and I can use the FN key to adjust its brightness), the screen stays dark, and after 30-60 seconds the CPU fan kicks on high.
Since I do not know for a fact that flashing bios e1792ims.119 worked back in May to fix this (and searching my computer for files from that time shows that I downloaded quite a few BIOSs for MSI laptops using the same board (dont do that…)) I’m going to try the only other pe70-2qd bios I can find which is e1792ims.109.
Otherwise, I get to try the very arduious task of flashing the old rom backups one at a time until one works. As I’m typing this post I’m remembering more from the last time I did this, and reflashing like 20 old rom copies until one worked ended up being the fix… That’s going to suck now that my board is being a bear about making me remove the chip every time.
I suppose if it comes down to needing to try a bunch of old, terribly named, backup roms I’ll have 10 chips to load up to cycle through, that’ll maybe make it a touch easier.
EDIT: OOOOHHH!!! I have some backups of just the bios (6,144kb) from AFUWIN way back when I first messed around with this that dont have the intel ME section (makes it 8,192). Does anyone know how I could figure out what address to start writing at for only the bios section?
The bios can be found here
https://www.msi.com/Laptop/support/pe70-2qd
EDIT 2: Oh, duh, I could just look at both of them in HxD, and search for the first string. The bios part starts at 00200000, how would I go about writing from that offset on with any of the available software tools?
EDIT 3: Haven’t removed the chip yet to reflash, tried with the test clip again and when I finally get a good connection all I get is a constant loop of either the ID or 08805f repeating. However it does appear to complete the writing process so I’ll have to put some obvious bits on the first line to check when I pull the chip again. Also I’m not too sure if the files I found are actually the stock backup or if they are something else, looking at them I still see the “to be filled by oem” lines. How does one go about looking for the info you dont want to lose in a bios file?
EDIT 4: Figured out how to make that (hopefully) original bios backup file write to the correct offsets: Simply copied it in HxD and inserted it into a fresh image at the correct offset. I’ve tried to flash it with the test clip several times with AsProgrammer 1.4.0, CH341A Programmer v1.3.4 and they run for the correct amount of time but the laptop still will not boot past the keyboard lighting up. I’m going to guess it’s completely on the clip getting a garbage connection and it trying to power a good part of the board at the same time. The power LED was a bit brighter and the run LED was way brighter with the chip directly attached.
Yes, I know about the sreg stuff, but nothing that happens in programmer (oddities) matters until we know why and can solve that CS# high/Low issue
Sounds like you may know more about how these work than I do, so you’ll have to help me from now on 
Lots of solder and flux usually can pop off a lead free solder chip, you just have to be careful you don’t melt anything by trying to long or pressing too hard. Blob on there and heat, wipe that off (so it takes off some of the lead free with it), then repeat that a few times, and then it will pop loose much easier eventually.
I would not use braid, unless you are super familiar with working using that and lead free solder. I find it usually makes removal more difficult, and higher risk of damaging or removing something else (tiny 0402 resistors etc)
Nice you finally got it off without issue, I’ll leave the above in case it’s helpful info for someone later.
If you can’t read a chip properly, then writes will fail as well, use another software version, or different software, or other ID’s etc.
You’re edit #4 is correct, and if that is known working BIOS region + we know stock FD/ME region above that is good, then this should = bootable BIOS, unless write is failing (Do it off-board and try again) After you do that, before you solder it back on the board, dump it and make sure it’s exact hex match to what you wrote.
Stock BIOS if 8MB should also be directly programmable and bootable, you will loose board specific info this way but that can be fixed later.
Sorry if I came off rude or blunt on the sreg, that wasn’t the intention at all 
It just seemed unnecessary to point out that both the edit sreg and unprotect buttons were failing in the post as they appeared to be essentially the same function except one has some logic behind it. I need to work on how I respond to people.
Thank you for the soldering tips, it was easier than I imagined it would be. It’s in a fairly exposed area and the closest resistors are about 2.5mm from the pad giving you a ton of room to get in there and tap the legs with the iron. There is enough room to get all 4 legs on the one side in one shot, then with that side lightly lifted with tweezers, popping the other side off was a chinch. To keep everything from getting too hot with the 30w firestarter I would only touch it for maybe a full second at the very most and would blow on it immediately (only during removal, don’t want any cold solder joints) to ensure the chip never got too hot and or that the nearby resistors wouldn’t float off their pads. I didn’t have any solder braid or flux but I did at one point make a small piece of diy wick from some fine strand copper wire to remove a little dot of excess solder from one of the eeprom legs since my diy syringe desoldering pump failed (a spring from a test clip stretched out isn’t long enough and is far too stiff). Being subscribed to a ton of electronic repair youtube channels the last 10 years or so probably helped things along a little. If it wasn’t for that, there is no way in hell I’d even attempt this, or if I did, I probably would have wiped off most of the nearby resistors by overheating the board.
I’m not entirely certain how writes are making it through when reads cannot, it really doesn’t sound logical at all on the surface. But looking at ‘Figure 30. Program/ Erase flow with read array data’ on the datasheet, maybe the constant loops that are executed during the writing of each block has something to do with it. The read command only happens the one time, then it automatically increases the address so the whole memory can be read with that single instruction. Considering how much of a load trying to interact with the chip while it’s mounted to the motherboard puts on the CH341a programmer, combined with a fairly poor/high resistance connection with the bios eeprom due to the clip, and the super chinsey leads that are soldered to the clip, there probably is a crazy amount of voltage/current drop happening between the programmer and the eeprom and maybe it needs a loop like that to successfully write and, more importantly, raise C# enough to kick it out of deep power state or whatever is happening. However, I have literally no clue if any of this is sound or if I’m rambling like a guy in full dunning-kruger mode.
Whenever I get around to pulling the chip again and trying the rebuilt file I’ll post an update. Might be later tonight, hard to say.
No, you’re good, I didn’t think like that at all I was just saying that stuff didn’t matter until we could resolve the main issue. I didn’t realize what you meant about that in regards to unprotect until you said it just now, so my bad there too!
Nice to hear you had plenty of room to play with soldering iron, and that it came off easier than expected 
Sounds like you were able to switch them around pretty easy, I’d hate to do such work without at least some flux, especially for putting back on, it makes things flow so much easier and cleaner.
But yes, I know the spot you’re in and have done similar re-work myself without flux in a pinch too.
At least once you pop it off again, you’ll be able to read after a write then correct? Or, can you not read with it off the board either?
If you can’t, then there’s no way to check/dump/confirm that the write happens properly byte-for-byte, so when it fails after you put back on you wont know if it’s due to failed write because of wrong software version, or just never wrote anything at all etc.
With the chip off it reads and writes without a single hiccup.
Got around to pulling the chip again last night and flashed it with the fixed bios image. It’s still behaving as if there is a bad flash…
At this point I have no idea what to do so I’m going to walk away. Once I get the flash chips in, I’ll try flashing various bios versions onto them and maybe try that. They should be in later this afternoon.
However, I’m going to guess that I fried something on the board and that to get this laptop working again it’ll need a fresh mainboard. That’ll be roughly $300 on ebay and I can resell the current board for approx $50 based on the current prices.
At the very least I can use this as a minor upgrade opportunity as the PE70-6QD is a fairly cut down model of the series that only has 1 of the 3 available M.2 storage ports, which eliminates m.2 raid, it only had an 950m where some of the others have a 960m, and I should be able to get an i5xxx or even a i6xxx board since this motherboard series ran a very long time. EDIT: Just looked at for $260 I can get a 5700hq/950m/3x-m.2 port board.
Well, I’ve got a slight change. With one of the eBay chips flashed to .116 (update between 109 and 119) instead of the keyboard lighting up, screen staying black then high speed CPU fan after 30ish seconds, I get lit up keyboard, black screen then the keyboard going dark after about 20 seconds.
Turns out I was wrong about the slight change, not sure what was causing it to turn off after 20 seconds but when I tried to turn it on today it did the usual “keyboard lights up, cooler boost button works, keyboard backlight control works, no MSI logo and after 30-60 seconds the CPU fan kicks on”(basically everything that. So I wiped and flashed the stock bios chip to the newest bios version fresh from the MSI site (119), removed the ebay chip (116) and reinstalled the freshly flashed stock chip. Absolutely no change.
For giggles I tried turning on the board without any bios chip installed to see if there would be a different reaction and there was not. I suppose this would make sense as a bad flash is no different than having no chip installed.
After spending several hours pouring over the MS-16J2 /1792 schematic, I’m at a complete loss to why this isn’t working. There are no missing (that aren’t supposed to be) resistors around the bios chip, I double and triple checked that all the solder points on the chip were solid, and even went through the EC reset procedures more times than I can count. Heck I even ended up digging through every thread in the MSI section of http://vlab.su/viewforum.php?f=60 and despite the russians doing some seriously advanced motherboard repairs I found nothing of any real use other than links to schematics.
Could this somehow be the EC firmware being bad? It was perfectly fine before I bricked the bios and it appears to be in working order (power button works, keyboard lights up, FN commands work, etc) so I’m hesitant to yank it off.