@Phoenix48

Quick question, shouldn't I edit the ini first though? I mean shouldn't I include the proper vendor ID number and device ID in question? Or will that be overwritten anyway after flashing occurs?

EDIT: OK, to answer my own question, YES I must edit the ini file with the correct info, otherwise it does NOT write the firmware.

However, even though it clearly appears to write the firmware and Verifies it, when I do a Verify it says its a mismatch. And when I reboot it still shows 2020 in the device manager. I am wondering if the Device Manager is telling me the truth? QUESTION, is there a command that will tell me the current firmware version? Below is the output I just got

C:\fw>W201FW21.exe /srom 0 /log /write K2024.mem cfg201v3.ini
[Target Device]Bus:0x03 Device:0x00 Function:0x00
This Device is uPD720201(Revision 3).
Erase Serial ROM....  100%
Erase complete
Write Serial ROM....  100%
Write complete
Verify Serial ROM....  100%
Verify complete
 
C:\fw>W201FW21.exe /srom 0 /verify K2024.mem cfg201v3.ini
[Target Device]Bus:0x03 Device:0x00 Function:0x00
This Device is uPD720201(Revision 3).
Verify Serial ROM....  100%
ERROR::Verify mismatch!
 
C:\fw>
 

Oh, and I forgot to mention that I checked the "backup.mem" file and it is TWICE the physical size of the K2024.mem file. Not sure what to make of that. And it makes me want to try flashing the backup.mem just to see what happens. lol



EDIT: Oh Boy, what the heck does this mean? I have TWO firmwares on my device, 2018 AND 2020? LOL, and what is with the FFFF ???? What the FFFF is going on? haha

C:\fw>w201fw21.exe /srom 0
Bus:0x03 Device:0x00 Function:0x00
This Device is uPD720201(Revision 3).
     FW Version : 2.0.1.8
     PCI Subsystem Vendor ID : 0xFFFF
     PCI Subsystem ID : 0xFFFF
 
     FW Version : 2.0.2.0
     PCI Subsystem Vendor ID : 0xFFFF
     PCI Subsystem ID : 0xFFFF
 
C:\fw>
 

This is interesting. The last few paragraphs seem to suggest that a tool with SSID and SVID can be set to not flash on target systems it was not designed for. I found this txt file on the IBM servers.

https://delivery04.dhe.ibm.com/sar/CMA/X...in2k8_32-64.txt

Please try another pcie in your motherboard. I am bet that your card don't make a good contact with all the pins.

@SkOrPn

Now i think i know exactly what is your problem. You new file is not for the same type of chip, or at least its the firmware code only and was not adapted in size for a specific type of chip and must be modified accordingly to fit your type 3 chip (the space on it). You can try the following:

- Donwnload my flasher for uPD720200AF1(uPD720200)/uPD720200A. Don't flash it, it is not for your chip. But it contains some elements that you will use with the first flasher i gave you.
- First element: Read ALL in the instructions file i wrote in it. It gives ALL the usefull infos for flashing the right way with the first flasher. But don't flash yet, you must first modify something.
- Use your first flasher with the /srom ? command to know your "Type : x" chip. I think your chip is a type 3 = Winbond.
- Use the /? command to get all the descriptions of all the commands. You should see in the description of the SROM type (probably Winbound) that it requires a file of x Kb in size. (each type of chip has a different size of space available in it and requires a file in the same size)
Note: Your problem is somewhat related to what i said in the first place. Your 2024 file has a size for a different type of chip and you must convert it in a size for a type 3 chip.
Edited: Forget that last part. Contrary to the uPD720200AF1(uPD720200)/uPD720200A, the new flasher for 201 is not telling the size of the file required. So we will use a work around:

- Open a known working file with HxD editor (your backup.mem will be perfect) and the new update file too (2024). Now you simply should have to add FF everywhere after the end of the codes (usually ending with 00 00) untill it gets to the same size as the known working file and modify the two last ones in the end to be "AA 55" instead of FF. (In the flasher you just downloaded, you can take a look at my backup.mem and the F303408.mem as a reference to give you an idea of what it should look like.)

(All that is the prefered way to do it because you have your (precious) backup.mem file. If you would not have it, then i would have recommended the use of the /erase command before trying to flash again the new firmware.)

It may also help to flash it with /srom 3 instead of just /srom 0. This will tell the flasher specifically that it is a type 3 chip instead of relying on the autodetect. You do the same with the /srom 3 /verify command.

With the file being the right size, this should also overwrite your old remaining codes from your old firmware that are still on your chip. This is why your system is reporting 2 firmwares on it. You should have only one reported after this. Same for the mismatch problem, the verify process must have detected the old remaining codes still on the chip. Now it should pass the verify process.

Yeah I tried /srom 3 yesterday to see what happens and it worked just fine. Seems weird to me that it would flash the new firmware and say it completed but then a verify says otherwise. When you flash it also verify the flash too. So a second verify fails?

Another thing I want to do today is to verify the backup just to witness a proper working verification process, just for my benefit. Someone told me that I might have another Renesas chip but I think that is impossible. My old p5b only has Intel ports and this card clearly only has one chip on it.

I'm glad you have figured it out. I will report back later today. Thanks again for the help, it's highly appreciated.

Here is the /srom ? output

C:\Windows\System32\0>w201fw21 /srom ?
Bus:0x03 Device:0x00 Function:0x00
This Device is uPD720201(Revision 3).
 W25XxxV series(Winbond), Product ID = 0x00EF3012
 

And here is the /? output for information on what W201FW21.exe can do.

C:\Windows\System32\0>w201fw21 /?
Serial ROM Utility for uPD720201(Revision 2 & 3)  & uPD720202(Revision 2).
Usage::
W201FW21 [ /? | /srom romtype | /write file1 [file2] [file3] | /dump file1 |
          /erase | /noerase | /log [file4] | /address deviceaddress |
          /fout file5 | /verify file1 [file2] [file3] |
          /writeall file1 [file2] [file3] ]
 
Options::
 /?          :Display this help message.
 /srom       :Specify SPI-Flash-ROM device type.
 /write      :Write both file1(.mem) and file2(.ini) to SPI Flash ROM.
              If need to write EUI-64, specify file3(.eui).
 /dump       :Dump ROM Image File from SPI-Flash-ROM.
 /erase      :Erase all of the data in SPI-Flash-ROM.
 /noerase    :Erase process is skipped. This command is used with write
              command if needed.
 /log        :Generates log file named file4.
              (Default log file named "log.txt")
 /address    :Specify one target device with PCI Device Address.
 /fout       :File out to file6 (Don't write to SPI-Flash-ROM).
 /verify     :Verify the ROM image data (Don't write to SPI-Flash-ROM).
 /writeall   :Write both file1(.mem) and file2(.ini) to SPI Flash ROMs
              of multi Host controllers on same system(computer).
              If need to write EUI-64, specify file3(.eui).
 
Where::
romtype       :Serial ROM type number (0,?).
Please see the supported list.
                  0. Auto Select (check serial rom type automatically)
                  Supported Serial Flash ROM List
                  - 25Lxx/6 series(Macronix)
                     (Product ID = 0x00C220XX)
                  - 25Lxx21E series(Macronix)
                     (Product ID = 0x00C222XX)
                  - W25XxxV series(Winbond)
                     (Product ID = 0x00EF30XX)
                  - Pm25LD512C/512C2(Chingis)
                     (Product ID = 0x019D20XX)
                  - M25Pxx-A series(Numonyx)
                     (Product ID = 0x00202010)
                                   0x00202011)
                  - M25Pxx series(Numonyx)
                     (Product ID = 0x00202012
                                   0x00202013)
                  - AT25F512B (ATMEL)
                     (Product ID = 0x001F6500)
                  - A25Lxxx series(AMIC)
                     (Product ID = 0x003730XX)
                  - EN25Fxx series(EON)
                     (Product ID = 0x001C31XX)
                  - SST25VFxxx/A series(SST)
                     (Product ID = 0x00BF0048
                                   0x00BF0049)
                  ?. Check Serial ROM Information.
file1         :Firmware File (extension is mem) released by Renesas Electroncis.
file2         :Configuration File (extension is ini) including system dependent
               Parameters such as PCI Subsystem ID or PCI Subsystem Vendor ID.
               Renesas Electronics releases a sample file. User need to modify
               those parameters in accordance with the customer system.
file3         :EUI-64 file(extension is eui) that includes EUI-64(XX-XX-XX-XX-
               XX-XX-XX-XX). If the Product is hot-plug device such as Express
               Card, the EUI-64 must be set. This requirement is released from
               Microsoft Windows Logo Program. As for the EUI-64, refer to the
               following WEB site.
                   http://standards.ieee.org/regauth/oui/tutorials/EUI64.html
file4         :LOG File Name. In case of skipping the filename4, log.txt is
               generated on the current directory.
file5         :Output Serial ROM Image File.
deviceaddress :Format is XX-YY-ZZ. XX is PCI Bus Number(HEX). YY is PCI Device
               Number(HEX). ZZ is PCI Function Number(HEX). If there are
               multiple devices on the system, user can specify one device.
 
Example::
        >W201FW21
        >W201FW21 /srom 0 /write K2xxxxxx.MEM CFG_201.INI
        >W201FW21 /srom 0 /write K2xxxxxx.MEM CFG_202.INI
        >W201FW21 /srom 0 /erase
        >W201FW21 /srom 0 /address 04-00-00 /write K2xxxxxx.MEM CFG_201.INI
        >W201FW21 /srom 0 /address 04-00-00 /write K2xxxxxx.MEM CFG_202.INI
        >W201FW21 /srom 0 /verify K2xxxxxx.MEM CFG_201.INI
        >W201FW21 /srom 0 /verify K2xxxxxx.MEM CFG_202.INI
        >W201FW21 /srom 0 /writeall K2xxxxxx.MEM CFG_201.INI
        >W201FW21 /srom 0 /writeall K2xxxxxx.MEM CFG_202.INI
 
C:\Windows\System32\0>
 

Do you notice in the Example:: section that there is no indication of a K3xxxxxx.mem file in existance? I wonder if when this 2.1.0.0 flasher program was written that they hadn't yet (or never did) made it to firmware 3 series? Even if that was the case they still uses a firmware beginning with a 2. I have now seen Firmware versions starting with K2024 and some with an F2024 (like from that Russian site). If only I knew why. Most of the ones I have all start with the K2.

I now wonder if my first flash attempt days ago using W201FW21.exe actually overwrote the proper K3 firmware? Like it said before it said it wrote it 100%, but I never verified it. I now wish I had backed up the mem when I first installed this card. lol, but the good news is the card still works perfectly as it is today. So I haven't broke it yet... Yay, lol

EDIT: On second thought, I am sure when I first installed it I checked the firmware version from within device manager and it clearly said 2020, that hasn't yet changed. I still just do not understand why it says it is writing the files, but not really. So it is writing HALF of the chip with 2024, but not the part that reports version number?

I will follow your instructions after a large cup o coffee. Thanks again.

Quick question. What should I be using in the INI file

[SubSystemVendorID]
FFFF
[SubSystemID]
FFFF
 

OR

[SubSystemVendorID]
1912
[SubSystemID]
00000000
 

The first is what is reported by the flasher, FFFF, and the later is what is reported by AIDA64 and microsofts very own USB View, not to mention also what is read in the device manager.

You should put there the same Vendor ID and System ID that you had when you were using the original backup.mem in your device manager. Probably 1912 for vendor ID and another real number for system device ID. I do not recommend to put either FFFF or 00000000 there. If in doubt or you just don't know at this point, then flash back the original backup.mem file, reboot, and go look again at what are the real IDs in device manager.

Edit: Forgot to say that all .mem files beginning with a K are for 201/202 chips series. And .mem file with a F are for uPD720200AF1(uPD720200)/uPD720200A. So a F2 file is a revision 2 file for uPD720200AF1(uPD720200)/uPD720200A. F3 is revision 3 and F4 is revision 4. Obviously, they don't seems to work like that with the K series because those flashers clearly states that a K2 files applies to 201 chips with revision 2 and 3 and 202 chips with revision 2.

This also means that there was in total 2 revisions (not counting the original that seemed to nerver have been in production) for your 201 chip and a total of 10 types of chips with either 201 or 202 (yours is type 3 Winbond).

@SkOrPn

I made some tests of my own. I had still my backup.mem of my original firmware and put it back to see how device manager listed it. I have a uPD720200AF1(uPD720200) chip (type 2, revision 3). My device hardware ID is:

PCI\VEN_1033&DEV_0194&SUBSYS_50071458&REV_03|PCI\VEN_1033&DEV_0194&SUBSYS_50071458|PCI\VEN_1033&DEV_0194&CC_0C0330|PCI\VEN_1033&DEV_0194&CC_0C03|

What pushed me to make thoses test is that i realised that the cfg.ini file ask for the [SubSystemVendorID] and the [SubSystemID]. The "SUB" part got me thinking... Because if you look at my hardware ID, you see there is a SUBSYS number that has NOTHING to do with the Vendor ID (VEN) and the Device ID (DEV).

So i put my theory to the test and entered what any normal person would do. I entered 1033 and 0194 for each respectively. After rebooting, i ended up with:

PCI\VEN_1033&DEV_0194&SUBSYS_01941033&REV_03|PCI\VEN_1033&DEV_0194&SUBSYS_01941033|PCI\VEN_1033&DEV_0194&CC_0C0330|PCI\VEN_1033&DEV_0194&CC_0C03|

So i thought, ok, i must really input the original SUBSYS number. So i entered 1033 and 50071458. After reboot, i ended up with:

PCI\VEN_1033&DEV_0194&SUBSYS_14581033&REV_03|PCI\VEN_1033&DEV_0194&SUBSYS_14581033|PCI\VEN_1033&DEV_0194&CC_0C0330|PCI\VEN_1033&DEV_0194&CC_0C03|

This is where i finally realized, and it took me some time, that the 1033 wasn't coming from the VEN (vendor) at all but instead from a SUBsystemvendor ID. I mean literally. Now i had finally understood how that system worked!

It turns out that the SUBSYS number is BOTH the [SubSystemVendorID] and the [SubSystemID] combined and inverted. Meaning the [SubSystemID] is the first 4 digits and the [SubSystemVendorID] is the 4 last digits in the SUBSYS number.

So i entered 1458 [SubSystemVendorID] and 5007 [SubSystemID] and after reboot, i got this:

PCI\VEN_1033&DEV_0194&SUBSYS_50071458&REV_03|PCI\VEN_1033&DEV_0194&SUBSYS_50071458|PCI\VEN_1033&DEV_0194&CC_0C0330|PCI\VEN_1033&DEV_0194&CC_0C03|

That is now identical to the first hardware ID i had before the firmware update.

So those are the right numbers to enter there to not change the hardware ID of the device while updating the firmware.

This also means that there are probably almost no one out there that enter the right numbers when they are asked to do so...

Edit: I forgot to say that the last one was also the only time that Windows didn't remove my Renesas USB 3.0 drivers to replace them with the generic ones from Microsoft after rebooting. Which is another proof that those are the right numbers to enter.

For confirmation ONLY. What is what please?

[SubSystemVendorID]
FFFF
[SubSystemID]
FFFF

According to thoses images. It is 0000 and 0000. (The SUBSYS ID with 8 zero in it)

If those are the numbers from your original firmware, then it is right numbers even if it looks weird to be just zeros.

If it is not from the original firmware, the only way to know the right numbers is to flash back the original firmware file (backup.mem) without using the cfg.ini file in the command. Then reboot.

If you don't have the original firmware as backup.mem, then those numbers are lost and you need to ask someone with the same system who never updated it what is his SUBSYS number.

OK, just to make it clear then. I have "00000000" listed as my SUBSYS, BUT I flashed this chip with the Intel 201_rear.zip without changing anything at all. The ini from that zip uses Intel's VEN and SUBSYS of
(From Intels cfg201v3.ini file)

[SubSystemVendorID]
8086
[SubSystemID]
4953
 

But yet my SUBSYS is clearly shown as 00000000, lol. Maybe I should try only four zeroes instead? so 1912 and 0000? perhaps?

OH, and I forgot to mention something. When I did a verify today of my backup.mem file, the system instantly took a dump, like something pulled from the USB ports, and the Renesas card showed an error in the device manager. However, it fixed itself the moment I did a "Update Drivers" and its still working just fine albeit with the generic Microsoft drivers. I updated the drivers again to 3.0.23.0 and its working perfectly. So the card is still OK.

Try to install Hardware identify and see your SUBSYS number to see if it is still reported as only 00000000.

Edit: I admit that with:

[SubSystemVendorID]
8086
[SubSystemID]
4953

Your SUBSYS should have become 49538086

Hardware ID



Do you see IT? I now see where the flasher is seeing FFFFFFFF

So your system is really reporting the SUBSYS as 00000000 and the SID as FFFFFFFF.

Now i wonder why the flasher don't change those when you use the cfg.ini file...