-
WANTED: Happy members who like to discuss audio and other topics related to our interest. Desire to learn and share knowledge of science required as is 20 years of participation in forums (not all true). Come here to have fun, be ready to be teased and not take online life too seriously. We now measure and review equipment for free! Click here for details.
SMSL M500 - Owners' Thread
- Thread starter TC!!
- Start date
- Joined
- Apr 28, 2019
- Messages
- 351
- Likes
- 119
Hi @SMSL-Mandy and @SMSL_Liu can we know why some of us can update to SW 1.8/2.01 while others are stuck at 1.5 like myself? Are you guys doing something to sort your SW issues or should people just start looking elsewhere for reliable products? Thanks
I have tested the MQA functionality on the M500 , by using test files from 2L.no/hires/
Selecting an MQA file from the available options for test, proved that an MQA file is not being recognised and is played as a HIGH RES 384KHz file , but no decoding or rendering of the MQA unfolding is being executed.
Surely this is not correct , or am I missing something?
OK changed the rate and bit depth in Windows 10 sound settings .
MQA now recognised !!
Selecting an MQA file from the available options for test, proved that an MQA file is not being recognised and is played as a HIGH RES 384KHz file , but no decoding or rendering of the MQA unfolding is being executed.
Surely this is not correct , or am I missing something?
OK changed the rate and bit depth in Windows 10 sound settings .
MQA now recognised !!
Last edited:
Hello all. First time here. I am a senior, independent developer with XMOS devices and a hardware developer with 35+ years of experience at our company here in Windsor, Ontario, Canada.
Coming here from the XMOS user forum after a discussion with another SMSL customer:
https://www.xcore.com/viewtopic.php?f=26&t=7915
Fairly confident that there is now an understanding on what is the issue with these boxes that are reverting back to the 1.05 firmware and refuse to accept an update after this upgrade procedure.
At this time, do not believe it will be possible to fix via software although still researching the tools that are most likely embedded inside your firmware.
Hardware fix is logical and respectively why the factory is asking for the product to be returned back to their office in Shenzhen.
Have some questions and welcome feedback:
1) Are there any owners of this product and also happen to be hardware developers (with respective tools)?
2) Any chance someone is in (Ontario?) Canada with one of these boxes? We really do not wish to purchase a unit off Amazon for R&D to debug this case unless we can at least recover the product cost. We are not audio developers but tossing around the idea of building such products. If you are comfortable with the idea, send us a private email and the unit for loan, we will then repair the unit and return back to you at our expense - best if you are in Canada but USA would work as well.
Our company has been designing h/w products for 35+ years and supporting XMOS designs for the past 10 years.
The root cause is related to the XMOS DFU tool having a bug that demands that the upgrade firmware be compiled on a specific version (or higher) of the compiler.
The fix is to locate the 8 pin SMD (surface mount flash IC) -> desoldering it is best -> make a backup of the firmware -> locate the corrupt firmware inside this flash -> erase the sectors containing the corrupt upgrade image. Solder back the flash device. Upgrade again to the latest version.
The alternate plan is to use a zero force 8 pin spring clip (SOIC) adapter to piggy-back the same soldered part -> place the entire PCB into #RESET mode (ie. ACTIVE LOW so ground it) -> this will then tri-state (high impedance) the 8 pin FLASH device so that an external SPI bus master can be used to re-flash the same corrupt flash device.
The above process has to be confirmed with a true corrupted M500 but very confident this to be the root cause and immediate resolution.
In hindsight, it would have been wise to incorporate a rather simple onboard SPI flash programmer for such corner cases like this one to fix "bricked" firmware.
Bye for now.
Adding what is believed to be the root cause document (summary: external SPI flash is now corrupt for the upgrade image and the DFU tool is confused and using the factory original & known good firmware @ 1.05 but also preventing the use of the DFU tool to further upgrade the box):
https://axxonshare.s3.amazonaws.com...returned-in-libflash-and-libquadflash_1.0.pdf
Coming here from the XMOS user forum after a discussion with another SMSL customer:
https://www.xcore.com/viewtopic.php?f=26&t=7915
Fairly confident that there is now an understanding on what is the issue with these boxes that are reverting back to the 1.05 firmware and refuse to accept an update after this upgrade procedure.
At this time, do not believe it will be possible to fix via software although still researching the tools that are most likely embedded inside your firmware.
Hardware fix is logical and respectively why the factory is asking for the product to be returned back to their office in Shenzhen.
Have some questions and welcome feedback:
1) Are there any owners of this product and also happen to be hardware developers (with respective tools)?
2) Any chance someone is in (Ontario?) Canada with one of these boxes? We really do not wish to purchase a unit off Amazon for R&D to debug this case unless we can at least recover the product cost. We are not audio developers but tossing around the idea of building such products. If you are comfortable with the idea, send us a private email and the unit for loan, we will then repair the unit and return back to you at our expense - best if you are in Canada but USA would work as well.
Our company has been designing h/w products for 35+ years and supporting XMOS designs for the past 10 years.
The root cause is related to the XMOS DFU tool having a bug that demands that the upgrade firmware be compiled on a specific version (or higher) of the compiler.
The fix is to locate the 8 pin SMD (surface mount flash IC) -> desoldering it is best -> make a backup of the firmware -> locate the corrupt firmware inside this flash -> erase the sectors containing the corrupt upgrade image. Solder back the flash device. Upgrade again to the latest version.
The alternate plan is to use a zero force 8 pin spring clip (SOIC) adapter to piggy-back the same soldered part -> place the entire PCB into #RESET mode (ie. ACTIVE LOW so ground it) -> this will then tri-state (high impedance) the 8 pin FLASH device so that an external SPI bus master can be used to re-flash the same corrupt flash device.
The above process has to be confirmed with a true corrupted M500 but very confident this to be the root cause and immediate resolution.
In hindsight, it would have been wise to incorporate a rather simple onboard SPI flash programmer for such corner cases like this one to fix "bricked" firmware.
Bye for now.
Adding what is believed to be the root cause document (summary: external SPI flash is now corrupt for the upgrade image and the DFU tool is confused and using the factory original & known good firmware @ 1.05 but also preventing the use of the DFU tool to further upgrade the box):
https://axxonshare.s3.amazonaws.com...returned-in-libflash-and-libquadflash_1.0.pdf
Last edited:
| Thread starter | Similar threads | Forum | Replies | Date |
|---|---|---|---|---|
| K | smsl sp200 + m200 vs m500 | Combination Audio DAC and Headphone Amplifiers | 7 | |
| M | MQA via SMSL M500 on macOS not working | Digital Audio Converters (DACs) | 5 | |
|
Having a Feeling of Shame Gives Rise to Courage--SMSL M500 V2 | Digital Audio Converters (DACs) | 72 |
Similar threads
-
smsl sp200 + m200 vs m500
- Started by kobazik
- Replies: 7
-
MQA via SMSL M500 on macOS not working
- Started by Martin-Andersen
- Replies: 5
-
Having a Feeling of Shame Gives Rise to Courage--SMSL M500 V2
- Started by WolfX-700
- Replies: 72