Has your M500 updated the USB firmware to Ver1.08? If you keep the previous version, pop noise will appear when playing PCM 768kHz.
-
WANTED: Happy members who like to discuss audio and other topics related to our interest. Desire to learn and share knowledge of science required. There are many reviews of audio hardware and expert members to help answer your questions. Click here to have your audio equipment measured for free!
SMSL M500 - Owners' Thread
- Thread starter TC!!
- Start date
I couldn't update it to 1.08 >> keep showing 1.05
Read the last 4 pages of comments
mon2
Member
@w1000i - the link to the v2 firmware will not help at this time.
Please see my post here for details:
https://www.audiosciencereview.com/forum/index.php?threads/smsl-m500-owners-thread.9547/page-5
In summary, what is happening is that the factory has a "known-good" default firmware which in your box is v1.05. So no matter what happens, short of electrical damage to your box - under normal use - the v1.05 will continue to boot.
Due to a bug in the DFU (Device Firmware Upgrade) tool supplied by XMOS a few years ago, a case can surface where the NEXT upgrade results in a partial erase of the flash memory and also causes the memory check to fail. If the memory check fails (CRC), the factory default firmware will only boot.
The NEXT upgrade that failed is also not fully erased so you are also prevented from future upgrades.
We have pinged SMSL (yesterday to Kelly) to assist in the hardware details of the m500 as we have some questions but 99.9% sure it can be fixed by external hardware - even if they do not reply. Note - Kelly did help us in 2015 on another SMSL case related to firmware upgrades.
In deep study now to see if it can be fixed by s/w which we now are holding some hope that this may be possible. Will take some quality R&D time as there is very limited public documentation on the low level software used for this USB upgrade mechanism. In addition, the firmware from SMSL is encrypted.
Very disappointed that nothing official has been posted on a better resolution.
A key concern is that SMSL is "fixing" the box but that still may not allow for future upgrades - that is, this issue will continue to occur unless the factory resolves the root cause. So even v2.01 (or whatever the latest version is) - can only be "upgraded one time" and then will revert to the factory default. Same case as you have now. There really is no reason why the firmware cannot be repeatedly upgraded as required.
This is a serious production issue for all XMOS device manufacturers using the DFU mechanism.
We have been contacted by many end customers for similar cases - one repair shop in the Middle East sent us a picture of a mountain of defective XMOS devices. Unfortunately the manufacturer did not take care to protect the USB interface lines which can cause in-rush current with the USB cable (ie. keep the cable as short as possible). Such damage is permanent and we cannot extract the code out of even a known good and working box as the firmware is encrypted and will only boot if a secret key INSIDE the XMOS CPU is loaded. Summary, the box is now garbage. A $0.50 USD part could have protected this permanent damage and without care on the length of the USB interface cable.
Same issue with M-Audio whom we phoned to offer free advice - they laughed and never returned the call.
Hope that SMSL will reply to us soon to assist.
Please see my post here for details:
https://www.audiosciencereview.com/forum/index.php?threads/smsl-m500-owners-thread.9547/page-5
In summary, what is happening is that the factory has a "known-good" default firmware which in your box is v1.05. So no matter what happens, short of electrical damage to your box - under normal use - the v1.05 will continue to boot.
Due to a bug in the DFU (Device Firmware Upgrade) tool supplied by XMOS a few years ago, a case can surface where the NEXT upgrade results in a partial erase of the flash memory and also causes the memory check to fail. If the memory check fails (CRC), the factory default firmware will only boot.
The NEXT upgrade that failed is also not fully erased so you are also prevented from future upgrades.
We have pinged SMSL (yesterday to Kelly) to assist in the hardware details of the m500 as we have some questions but 99.9% sure it can be fixed by external hardware - even if they do not reply. Note - Kelly did help us in 2015 on another SMSL case related to firmware upgrades.
In deep study now to see if it can be fixed by s/w which we now are holding some hope that this may be possible. Will take some quality R&D time as there is very limited public documentation on the low level software used for this USB upgrade mechanism. In addition, the firmware from SMSL is encrypted.
Very disappointed that nothing official has been posted on a better resolution.
A key concern is that SMSL is "fixing" the box but that still may not allow for future upgrades - that is, this issue will continue to occur unless the factory resolves the root cause. So even v2.01 (or whatever the latest version is) - can only be "upgraded one time" and then will revert to the factory default. Same case as you have now. There really is no reason why the firmware cannot be repeatedly upgraded as required.
This is a serious production issue for all XMOS device manufacturers using the DFU mechanism.
We have been contacted by many end customers for similar cases - one repair shop in the Middle East sent us a picture of a mountain of defective XMOS devices. Unfortunately the manufacturer did not take care to protect the USB interface lines which can cause in-rush current with the USB cable (ie. keep the cable as short as possible). Such damage is permanent and we cannot extract the code out of even a known good and working box as the firmware is encrypted and will only boot if a secret key INSIDE the XMOS CPU is loaded. Summary, the box is now garbage. A $0.50 USD part could have protected this permanent damage and without care on the length of the USB interface cable.
Same issue with M-Audio whom we phoned to offer free advice - they laughed and never returned the call.
Hope that SMSL will reply to us soon to assist.
I screwed up and tried updating to 2.01 and now I am stuck at 1.5 as well. This is really unfortunate if I am really stuck at that version permanently . Please smsl fix this for us.
mon2
Member
@Ilumo, the issue is not permanent. The root cause is a code bug in the field upgrade mechanism (DFU). The earlier boxes released by SMSL contain the buggy DFU tool.
This means that the FIRST image (factory supplied) offers the DEFAULT firmware (in your case v1.5) + the buggy DFU tool. This factory default firmware never gets erased and is the fall back image.
When an upgrade is performed with this buggy version of the DFU, the upgrade firmware (SECOND IMAGE) loads and runs fine.
When yet another upgrade is attempted, this SECOND IMAGE is corrupted (intentional) but the DFU tool recognizes the image to be valid so the SECOND IMAGE of memory is not erased. This partial state of the SECOND IMAGE fails as a bootable image so the bootloader mechanism resets to run the only known good image which is the FIRST IMAGE (ie. v1.5 in your case).
Physically, these images are being stored inside the 8 pin device which appears to be the left of the XMOS CPU. The public pictures are not clear for the part values on these chips.
As we know from this forum and receiving an alert on the XCORE (XMOS) user forum, you are required to return the unit back to the factory. They have not confirmed the actual procedure on their fix but very confident that:
a) the unit will be opened, the surface mount flash IC will be erased and reflashed with the latest firmware (2.01?) which ALSO contains yet a fixed up DFU tool - we have this confirmation from SMSL already that the reflashed image will no longer have this issue.
b) with this fixed DFU tool, you will be able to continue to upgrade your box in the field
The referenced document in my first post from XMOS notes this bug and resolution which requires the use of the latest DFU firmware libraries from XMOS and the developer is also to use a current compiler version to generate this firmware.
Not sure but suspecting that the fees to send to / from SMSL Shenzhen is borne by the customer.
Does SMSL have a USA agent who can perform these (rather logical) upgrades?
The hardware method of fix is a very straight forward process. However this fix does involve some external tools.
We are still reviewing a possible s/w fix. As the details of this approach is not documented, it is consuming some time (and braincells). Still holding hope for this solution via s/w.
We did contact SMSL last weekend on Saturday. They did reply to us (director of Engineering included) on Monday and promised a follow up to numerous questions. Still waiting on this followup.
At the very least asking for a proper document on how to open this box properly.
Other are very hardware specific questions.
Only SMSL can supply details on which firmware and/or serial # of the M500 boxes are impacted by this firmware bug.
As we are not affiliated with SMSL, this research is also ne
Will write back once more is known.
This means that the FIRST image (factory supplied) offers the DEFAULT firmware (in your case v1.5) + the buggy DFU tool. This factory default firmware never gets erased and is the fall back image.
When an upgrade is performed with this buggy version of the DFU, the upgrade firmware (SECOND IMAGE) loads and runs fine.
When yet another upgrade is attempted, this SECOND IMAGE is corrupted (intentional) but the DFU tool recognizes the image to be valid so the SECOND IMAGE of memory is not erased. This partial state of the SECOND IMAGE fails as a bootable image so the bootloader mechanism resets to run the only known good image which is the FIRST IMAGE (ie. v1.5 in your case).
Physically, these images are being stored inside the 8 pin device which appears to be the left of the XMOS CPU. The public pictures are not clear for the part values on these chips.
As we know from this forum and receiving an alert on the XCORE (XMOS) user forum, you are required to return the unit back to the factory. They have not confirmed the actual procedure on their fix but very confident that:
a) the unit will be opened, the surface mount flash IC will be erased and reflashed with the latest firmware (2.01?) which ALSO contains yet a fixed up DFU tool - we have this confirmation from SMSL already that the reflashed image will no longer have this issue.
b) with this fixed DFU tool, you will be able to continue to upgrade your box in the field
The referenced document in my first post from XMOS notes this bug and resolution which requires the use of the latest DFU firmware libraries from XMOS and the developer is also to use a current compiler version to generate this firmware.
Not sure but suspecting that the fees to send to / from SMSL Shenzhen is borne by the customer.
Does SMSL have a USA agent who can perform these (rather logical) upgrades?
The hardware method of fix is a very straight forward process. However this fix does involve some external tools.
We are still reviewing a possible s/w fix. As the details of this approach is not documented, it is consuming some time (and braincells). Still holding hope for this solution via s/w.
We did contact SMSL last weekend on Saturday. They did reply to us (director of Engineering included) on Monday and promised a follow up to numerous questions. Still waiting on this followup.
At the very least asking for a proper document on how to open this box properly.
Other are very hardware specific questions.
Only SMSL can supply details on which firmware and/or serial # of the M500 boxes are impacted by this firmware bug.
As we are not affiliated with SMSL, this research is also ne
Will write back once more is known.
thanks for the quick reply on this. I did send an email to support and they responded That I would have to send it back for them to repair. That said I really prefer to wait for a software fix if necessary as I don’t feel like it right for the customer to have to bear the brunt of the shipping costs as well as the time to ship/repair which may take months with the current health crisis in play.
I just received the unit yesterday and was going through standard procedure of updating products to the latest firmware and this happened. Very unfortunate. I will keep tuned in to this thread to see what happens. The good news is that the dac/amp still works and does sound great. Thanks again.
So what is the latest update? Any word from smsl?
There are the details on my M500:
I have not tried updating the fw yet. Is correct to stay with fw where Im at for now until SMSL responds?
Also, anyone know what the warranty id on this dac/amp. Im at the point of returning this and purchasing something from another vendor that has better support and maybe a warranty department based in the US. Maybe spend a few hundred $$$ more and get a better device/support.
Also, seems like these dac/amps don't have any serial numbers?! At least none that I could see on the case or box. So how do they handle warranty claims?
There are the details on my M500:
I have not tried updating the fw yet. Is correct to stay with fw where Im at for now until SMSL responds?
Also, anyone know what the warranty id on this dac/amp. Im at the point of returning this and purchasing something from another vendor that has better support and maybe a warranty department based in the US. Maybe spend a few hundred $$$ more and get a better device/support.
Also, seems like these dac/amps don't have any serial numbers?! At least none that I could see on the case or box. So how do they handle warranty claims?
Your unit seems fully updated with the latest everything from what I can tell. Nothing to update.
Thanks for the feedback @XeNoNF50
For now, I will leave my unit alone and not try to update it until SMSL responds somewhere with some clear answers.
But, in the meantime, I loaded up the DFU tool to see what it would say regarding the unit and it states its FW is v2.01.
Very confusing you would think this would be indicated on this screen? Where it says SW: 1.6, you think it would say SW: 2.01 instead???
Cause right now there are few numbers that smsl needs to explain to the end user,
Screen above:
SW: 1.6
HW: 1.3
XMOS USBAudio Driver v4.67.0
FW 2.01 as reported by the driver/DFU Tool
The latest firmware was 2.01, which they pulled?!?
So is HW: 1.3 version a fixed/working pcb revision that is not affected by the FW update issue that seems to be happening to HW revision 1.2?
Is this unit misreporting its few version to the driver, etc..?
Theses are the FW revision notes from SMSL
Version note:
1.06 first release
1.07 fixed the android phones sound small problem! with canceling the volume adjust the function of USB.
1.08 fixed the 32bit can not be played.
V2.01 fw linked on this thread did not have any notes on it, but did include this file which I find odd:
XU216 read from flash.bin
Does SMSL have a support forum???
For now, I will leave my unit alone and not try to update it until SMSL responds somewhere with some clear answers.
But, in the meantime, I loaded up the DFU tool to see what it would say regarding the unit and it states its FW is v2.01.
Very confusing you would think this would be indicated on this screen? Where it says SW: 1.6, you think it would say SW: 2.01 instead???
Cause right now there are few numbers that smsl needs to explain to the end user,
Screen above:
SW: 1.6
HW: 1.3
XMOS USBAudio Driver v4.67.0
FW 2.01 as reported by the driver/DFU Tool
The latest firmware was 2.01, which they pulled?!?
So is HW: 1.3 version a fixed/working pcb revision that is not affected by the FW update issue that seems to be happening to HW revision 1.2?
Is this unit misreporting its few version to the driver, etc..?
Theses are the FW revision notes from SMSL
Version note:
1.06 first release
1.07 fixed the android phones sound small problem! with canceling the volume adjust the function of USB.
1.08 fixed the 32bit can not be played.
V2.01 fw linked on this thread did not have any notes on it, but did include this file which I find odd:
XU216 read from flash.bin
Does SMSL have a support forum???
Last edited:
Don’t get confused:
These „FW-Update“ (1.06, 1.07, 1.08, 2.01) are about the USB-Interface. It’s the firmware of the Xmos Chip who is responsible for the USB-Interface/Communication. (This is also the Version you see in the update tool or in the xmos-driver-control panel on your pc)
The Version Info displayed on the device do not show the USB-Interface Version.. it shows the Firmware Version of the “stuff” behind the USB-Xmos chip.
SW: 1.6 -> Software Version of the device/ the "stuff behind" the usb interface (the published firmware updates are not about this and will not change it)
HW: 1.3 -> Hardware Version/ Revision of the circuit board
XMOS USBAudio Driver v4.67.0 -> The Windows Driver to communicate over usb with the Xmos chip in the M500 (developed by an other company "thesycon")
FW 2.01 as reported by the driver/DFU Tool -> The Firmware Version of the Xmos in the M500
So your device seem to be the latest posible on the market and have all the latest versions in it.
Don't run this messed up updates for now (see also the very informative posts from @mon2)
Last edited:
Thank you very much, that clears up a lot of the confusion. I really appreciate your time/explanation.
I hope SMSL gets these issues resolved and get better customer support in place, clear instructions/guides on their site for their products. And everyone can hopefully get their affected units fixed at no cost. It should not be on the end user to pay anything extra out of pocket to get a manufacturer's defective product repaired while it is still under warranty, even shipping.
Yes you could. I'm running Tidal through mConnect/RPi4b/Volumio/SMSL M500/Power Amp. And no problems playing MQA files.
malevich244
Member
- Joined
- Jun 6, 2020
- Messages
- 9
- Likes
- 1
I just purchased an M500 (silver color) via Amazon and I have SW 1.4 and HW 1.2.
The DAC is excellent overall, but I have two issues. I have my headphones and speakers connected, and there is some line leakage in the speakers. I also can't get 32-bit audio to register with this device.
SMSL tells me to update the firmware, but I checked their site and I don't see any firmware available. How do I get the firmware from them?
Should I just return the unit I got and ask for HW 1.3?
If I return the M500 and they can't guarantee HW 1.3, is there another DAC/Headphone Amp that would be better suited for my HD800?
The DAC is excellent overall, but I have two issues. I have my headphones and speakers connected, and there is some line leakage in the speakers. I also can't get 32-bit audio to register with this device.
SMSL tells me to update the firmware, but I checked their site and I don't see any firmware available. How do I get the firmware from them?
Should I just return the unit I got and ask for HW 1.3?
If I return the M500 and they can't guarantee HW 1.3, is there another DAC/Headphone Amp that would be better suited for my HD800?
Strange that this was told to you. The firmware was withdrawn for months.
Just read the last 4-5 pages of this and https://www.audiosciencereview.com/.../smsl-m500-dac-and-hp-amp-review.9606/page-64 forum-threads.
There is probably a 50:50 chance that your M500 will fall back/ stuck on old firmware.
So updating is currently not recommended.
HW 1.2 and SW 1.4 sound like the first batch of the m500. Probably you see a date of 2019 on the info display?
As far as we know since then are 2 new revisions seen on the market (but there are no official info):
HW 1.2/ SW 1.5/ 2019-10-9
HW 1.3/SW 1.6/ 2020-3-2
So if returning is simple, maybe you can give it a try, becaus it sound like you get an old stock.
Last edited:
malevich244
Member
- Joined
- Jun 6, 2020
- Messages
- 9
- Likes
- 1
Thanks a bunch for this info. I chatted with them on Amazon and they said to update the firmware... I will try to get the newest M500 from SMSL.
My unit is dated 2019-07-28
My remote just stopped working, too. :/
mon2
Member
Hi. A bit of an update.
1) We have been contacted by Kelly and their engineering manager. Last week, forwarded a laundry list of questions to them to better understand the design of this box.
2) This weekend, received a dump of the v2.01 firmware that is stored inside the flash memory device (8 pin device) shown on the PCB somewhere in this forum. The clean idea is to replace this IC with another that contains this corrected firmware. However, this requires the use of hot air surface mount tools + opening the box. If practical, consider to do so with your local electronic repair shop. The memory device is very common and the programming is straight forward (QSPI flash memory @ 4Mb).
3) This v2.01 firmware is reported to contain the fixed bootloader & the latest firmware for your M500 box. That is, with this firmware, future upgrades will not face this quirk.
4) Waiting on the answers for our many questions but know that the XMOS document raised (my first post here on this forum) is the root cause. One of the questions is how to properly open the box.
5) We do not own this M500 box but trying to understand and simulate the environment with our assorted XMOS tools in the lab. The upgrade mechanism is also very restrictive on what can and cannot be done with the upgrades.
6) Just now forwarded an email with a potential idea to SMSL (see below). IF you have not performed an upgrade, do not do so unless you are confident that your box has the corrected FACTORY IMAGE with the corrected bootloader. Only SMSL can validate which boxes or firmware offer this corrected firmware. Have emailed them to ask at which firmware version was this code corrected.
If your box contains the buggy bootloader and an older factory image AND you have not performed any upgrades then in theory, it should be possible to fix the box using only software.
It should also be possible to fix such field units using software as follows:
create an UPGRADE image that will boot -> remove the write protect bits of the flash -> erase the factory supplied (old) bootloader + erase the Image "0" (aka factory image) -> write the contents of the 2.01 firmware as the factory image - all in a single pass.
This must be all done without a power failure else the unit will brick. Then only a hardware fix of replacing the flash will work.
So the concept is that this single time upgrade can be used as a mechanism to fix the factory firmware so that the issue is fixed by the end consumer. This is a very solid potential solution.
We are confident that the firmware is encrypted so this demands that SMSL must encrypt this special firmware so that upon boot, the secret keys inside the XMOS CPU can decrypt the upgrade image during runtime to perform this task. Unless the secret keys are used, the code will not boot.
Not clear if other SMSL widgets are impacted by this field upgrade bug. If it makes business sense, will consider to purchase a M500 to review this case and then resell afterwards. Ironically then would prefer an older (buggy) firmware unit.
Back to research...
Sorry - forgot to note that SMSL has noted that the M500 is NOT EOL in the last email.
1) We have been contacted by Kelly and their engineering manager. Last week, forwarded a laundry list of questions to them to better understand the design of this box.
2) This weekend, received a dump of the v2.01 firmware that is stored inside the flash memory device (8 pin device) shown on the PCB somewhere in this forum. The clean idea is to replace this IC with another that contains this corrected firmware. However, this requires the use of hot air surface mount tools + opening the box. If practical, consider to do so with your local electronic repair shop. The memory device is very common and the programming is straight forward (QSPI flash memory @ 4Mb).
3) This v2.01 firmware is reported to contain the fixed bootloader & the latest firmware for your M500 box. That is, with this firmware, future upgrades will not face this quirk.
4) Waiting on the answers for our many questions but know that the XMOS document raised (my first post here on this forum) is the root cause. One of the questions is how to properly open the box.
5) We do not own this M500 box but trying to understand and simulate the environment with our assorted XMOS tools in the lab. The upgrade mechanism is also very restrictive on what can and cannot be done with the upgrades.
6) Just now forwarded an email with a potential idea to SMSL (see below). IF you have not performed an upgrade, do not do so unless you are confident that your box has the corrected FACTORY IMAGE with the corrected bootloader. Only SMSL can validate which boxes or firmware offer this corrected firmware. Have emailed them to ask at which firmware version was this code corrected.
If your box contains the buggy bootloader and an older factory image AND you have not performed any upgrades then in theory, it should be possible to fix the box using only software.
It should also be possible to fix such field units using software as follows:
create an UPGRADE image that will boot -> remove the write protect bits of the flash -> erase the factory supplied (old) bootloader + erase the Image "0" (aka factory image) -> write the contents of the 2.01 firmware as the factory image - all in a single pass.
This must be all done without a power failure else the unit will brick. Then only a hardware fix of replacing the flash will work.
So the concept is that this single time upgrade can be used as a mechanism to fix the factory firmware so that the issue is fixed by the end consumer. This is a very solid potential solution.
We are confident that the firmware is encrypted so this demands that SMSL must encrypt this special firmware so that upon boot, the secret keys inside the XMOS CPU can decrypt the upgrade image during runtime to perform this task. Unless the secret keys are used, the code will not boot.
Not clear if other SMSL widgets are impacted by this field upgrade bug. If it makes business sense, will consider to purchase a M500 to review this case and then resell afterwards. Ironically then would prefer an older (buggy) firmware unit.
Back to research...
Sorry - forgot to note that SMSL has noted that the M500 is NOT EOL in the last email.
Similar threads
