@twixt
There is no way for me to say for sure that the update is absolutely sure, but I think you can use the same firmware. Firmware 130125_00_02_00 (ASM1042) was released for an Asus-RT-N56U router, while 130201_10_02_02 (ASM1042A) and 131025_10_11_03 (ASM1042A) was released for external cards like yours. But all these firmware have also been used for onboards controllers.
I haven’t found a firmware that it is onboard/external specific, but I can’t vouch 100% that you can use the same firmware. I guess you will have take a leap of faith, like anyone flashing any device.
Hello,
I have the Asus P8Z77-V
104xfwdl /A
DE0_000D.BIN
DE1_026D.BIN
update to Asmedia_asm104x_131025mod
update successfully
104xfwdl /D
error: can not find ASMT Host
104xfwdl /u backupfile.bin
error: can not find ASMT Host
104xfwdl /f
error: can not find ASMT Host
window Device Manager
can not show and work asmedia usb
Asmedia chip Out of work!
plz help
Hi lordkag, hope you can help me!
I have exact same mobo and exact same SVID/SSID as user zzbloopzz.
I downloaded FW from your post #36.
I have created DOS usb boot with RUFUS and was able to check SVID/SSID with /d parameter and was able to backup current firmware with /a
But if I want to do the update by running u.bat I always get following error :
Update failed, file not found (-7)
Any idea what I am doing wrong here?
Would really appreciate your help since I am having occasional hangs when plugging in USB devices.
Thanks in advance!
EDIT by Fernando: Unneeded fully quoted text deleted (to save space)
@ daffie:
Welcome at Win-RAID Forum!
I hope, that lordkag will see your post (it would have been better to start with “@ lordkag”, because this way he will get a PM).
Regards
Dieter (alias Fernando)
P.S.: Please don’t fully quote any post, because this method increases the thread volume and may drop the Forum performance.
I had same error. You have to manually update when you boot to USB. Type the following:
1. Type "dir"
2. Take a note of the full file name of 130125_00_02_00.bin.
3. Manually update by typing "104xfwdl.exe /u 130125_00_02_00.bin (whatever full filename is of BIOS)"
IE: For me, I had to type something along the lines of this "104xfwdl.exe /u 130125_00_~.bin" The reason for this I believe is because filename is too long so DOS shortens it.
The problem is the length of the firmware file (filename). Remember going back to the stone ages requires max file name length of 8 digits and max 3 digits extension.
So rename firmware file to 12345678.123 and edit .bat file (if required).
@zzbloopzz @mictlan
Thanks a lot both!
I feel so stupid, I never really worked with DOS before. It shows I guess… 
FW update was successful, let’s see if my lock-up problem is gone.
Will report back in some weeks to let you all know!
@lordkag
Firmware Update experience as follows:
1. Copied the files in the Archive attached to Post #36 to a bootable floppy disk.
2. Renamed the 130125_00_02_00 .bin file to 0125_200.bin - following the DOS 8.3 naming convention changeover used for previous Asmedia firmware files.
3. Edited u.bat to use DOS 8.3 filename - 0125_200.bin
4. Booted to DOS floppy.
5. Confirmed proper operation using d.bat
6. Ran firmware upgrade using modified u.bat
7. Firmware update noted as successful.
8. Reran d.bat to confirm updated firmware version within DOS session.
9. Powered down system.
10. Powered up system, booting from DOS floppy.
11. Reran d.bat
12. Confirmed that firmware update survived power down and restart.
Yes! It works!
Note: From what I can see - there are two forms of firmware:
1. The "104xfwdl.exe /A" command creates a 128Kb file - which as far as I am aware is a complete dump of the entire firmware-flash-memory space. If the dump is created before making any changes to the system - this file can be used to reinstall the firmware in its original state - should an error occur during a firmware-flash-update process.
2. Firmware-flash-update files are only 64Kb in size - which implies these updates only patch the "USB3 firmware space" - without touching the headers or bus interface configuration settings.
System Checks with new firmware in place:
1. Existing Asmedia Driver Version 1.16.16 successfully connects and integrates with updated firmware in Orico PASMUS3-2P Add-In PCIE Card - which uses an Asmedia 1042 bridge chip for the USB3 port.
2. New firmware and existing driver combination connects successfully to Oyen Digital MiniPro USB3/ESATA External Hard Disk - which uses an Asmedia 1053e bridge chip for the USB3 port.
2. There is a noticeable improvement in speed-of-response during bootup.
3. Most importantly - the intermittent problems with stalls during Return-from-Sleep have gone away - which was my hope for the firmware update.
Driver Update experience as follows:
1. Downloaded latest Asmedia USB3 Driver Set from Station-Drivers - Version 1.16.23 as of the date of this post.
2. Unpacked the archive and ran the AsusSetup.exe utility.
3. The AsusSetup utility launched the Asmedia USB3 Update utility, which removed the old Version 1.16.16 USB3 Driver and installed the newer Version 1.16.23 driver.
4. Tested the new drivers. Connection works through Return-from-Sleep.
Note: Do Not have your External Hard Disk active and running while performing the USB3 Driver Update!
When I tested this, the USB3 Driver Update would stall near the end of the update process until the External Hard Disk was Safely Removed from the System. Once the External Hard Disk was safely removed and powered off - even while in the middle of the Driver Update process - the USB3 Driver Update then completed normally. However, a Dialog Box appeared stating that the system was unable to automatically Format the drive letter assigned to the External Hard Disk. My Hard Disk in the Oyen Digital Enclosure was unharmed and worked normally once the system was restarted - there was no data loss. I am unaware as to whether my experience was a safety precaution built into my Oyen Digital MiniPro firmware - or whether this is a generic safety precaution built into the USB3 Driver Update process. Prudence would indicate it is wise to ensure all USB3 Devices are depowered or disconnected before performing the USB3 Driver Update process.
Background Info:
I have two motherboards here which exhibited problems with Return-from-Sleep.
These problems are probably caused by the same issues - where some users report External Hard Disks spontaneously disconnecting during use.
1. The first Motherboard is an Asus P5Q-Deluxe using the latest V2301 BIOS from Asus -
with a custom Firmware update for the Intel OROM to Version 10.1.0.1008 and an update to the Marvel 88SE6121 to Version 1.1.0.L73.
2. The second Motherboard is an Asus P5Q3-Deluxe - WiFi using the latest V2105 BIOS from Asus -
with a custom Firmware Update for the Intel OROM to Version 10.1.0.1008 and an update to the Marvel 88SE6121 to Version 1.1.0.L73.
Note: These motherboards are notoriously cranky when it comes to Memory Compatibility, SATA stability on the outboard Marvell Controller Chipset Ports, and Return-from-Sleep. They make an excellent testbed for compatibility issues with Hard Disk firmware and USB3 Addon Cards.
Hi, i dumped this from my Asus M5A99X Evo R2.0 BIOS Ver 2501
Idont now if is ASM1042 or ASM1042A (maybe is ASM1042)
Version 120524_00_02_6a
SVID 0x1043 SSID 0x8488
its possible update it?
Thx
act.zip (5.63 MB)
Your attached fw bu has header U2104_RCFG -> U2104_RCFG for 1042.
Update in post 36 is for 1042.
To update or not to is your decision. If you read the thread here you’ll notice that at least two guys killed their controllers by flashing wrong firmware.
If you decide to update do a visual inspection of the ASMedia chip on the mobo to see if it is really a 1042. You should have two chips.
READ the thread and check the stuff yourself.
A freeware hex editor is HxD.
I must admit that zzblooopzz, mictlan and twixt are equally right. In my attempt to give the file a clear name that would reflect the version, I forgot the DOS naming sequence. So I will reupload to this post the same firmware with the shorten name, for those that would run into the same problem without really knowing the culprit.
@twixt
The two firmware are one and the same, just that /A gives you a full dump of the chip, where the firmware starts at offset 0 and afterwards is just padding of 00 or FF bytes. You can confirm this with any comparison tool or even manually by splitting the bigger file right where the small one ends. I had more than one sample to test this, based on user input. I also have some newer Marvell OROMs, in the form of 1.1.0.L75 and 1.2.0.29 (edit: Fernando already has them or newer), but this is out of the scope of this thread. Make a request by PM if you want them and I shall post them in the “AHCI & RAID ROM Modules” thread.
@monta990
Thank you for the dumps, they are really helpful in building the bigger picture. You can listen to mictlan advice. The weird part is that your BIOS has already the latest firmware, but it hasn’t flashed it on the controller. So you better do this on your own.
While mictlan is right about the danger of flashing the wrong firmware, I must add some clarifications. The first user with a broken controller was Hanson, when he flashed a modded firmware prepared by me. I take this blame on me for skipping a few precaution steps and relying too much on Hanson’s programmer to save the day. I was in the process of learning and didn’t knew about 1042 and 1042A. It was shroeder that pointed this separation, in this post. The second user was vzsoft, who somehow missed the entire thread and went for the exact modded file. How on Earth he managed to do that, is beyond my understanding. How hard is to read a few posts before flashing a firmware, how hard is to miss the “mod” word in the firmware’s name, how hard is the read the very next post in which Hanson replied that his controller is broken? This is quite an achievement and is the reason why I haven’t help him, because users like him should learn the hard way to not blindly flash everything that lands in their arms.
ASMedia_ASM1042_130125_00_02_00.rar (170 KB)
@lordkag
So, from this I imply the "smarts" to adapt the firmware installation - to either an external PCIE Add-On card - or an embedded controller- are part of the firmware update executable? (104xfwdl.exe)
I will reply to the info regarding the Marvell and Intel OROMs in a post on the "AHCI & RAID ROM Modules" thread.
Thanks again for all your help.
@twixt
I’m not sure I follow your question/deduction. Are you referring to the fact that the firmware is touched by the flasher? If so, the answer is no. There is no before-after with this firmware, no customization done during flashing, not even during daily use. You can see this by dumping your current firmware and compare it to the one you flashed. They are the same in the first 64KB - the firmware space, the other 64KB are empty bytes, because the chip is 128KB. If there should be some settings stored in the chip, then it means the flasher ignores them during dumping and the only way to know for sure is dumping the chip with a programmer. But my guess is that the result will still be the same. The only customization that I’m aware of is the use of 104XFW.CFG, where only SVID and SSID can be changed.
@mictlan
It was just a script I made for easily finding and dumping new modules for UBU.
@lordkag
OK. Thanks for the info. I’m trying to understand this a little better - my intent is to be able to avoid bricking a motherboard USB3 firmware - if I understand the mechanism more completely.
Is there a difference between an outboard PCIE Add-On card and an inboard on-motherboard implementation?
Thanks for any further info you can provide.
You already tested the hardest case - an external card. The motherboard updating has been tested by a few other users, as you can read on this thread. As long as you take the right firmware, the risk is at minimum.
Hi,
I’ve been trying to run the firmware updater for asmedia but get an error message that I’m trying to run a 32bit app in a 64 bit environment?
Thanks.
Help be greatly appreciated.
PS: Anyone care to do performance benchmarks of usb3 per firmware driver version? Be interesting.
You need to create a bootable DOS USB Flash drive. Use a tool such as Rufus. Once bootable drive is created, copy contents to the flash drive then restart computer and boot from it.
I do not have any benchmarks, but after updating firmware my USB 3.0 is solid as a ROCK. No more sporadic computer crashes/freezing/hangs when I plug in random USB 3.0 devices. I have copied at least 150GB+ back and forth on random devices with out issue. Believe me, it was very frustrating so I had stopped using the USB 3.0 ports all together. I was even on the verge of upgrading my computer because I really need USB 3.0 speeds.
I am not the only one either. If you google Asus Z68 USB 3.0 issues, there are tons of threads on stability issues. People thought it was just a manufacturer defect, but thanks to this thread that is not the case. :c)
About two weeks ago, i flashed firmware on my Asus Maximus V Gene. It has ASM1042, i used firmware from post #36.
Also flashed discrete controller from Delock (Sata ASM106x and USB ASM1042 combo) with same FW, all worked well (but i can’t flash fw for sata controler on delock card).
Looks like I have a Nec uPD720200a chip. Oops. My mistake. Found appropriate module from the usual place and upgraded. Had to reset my device in device manager to get it to work though. Probably needs a driver reinstall now. Thanks for the help anyhow.