• 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

Roddy

Member
Joined
Oct 14, 2020
Messages
42
Likes
27
My remote stopped working. I tested the batteries. Or maybe something stopped working on the DAC itself. Any way to test it? I don't want to wear out the power button through presses.
 
Last edited:

ArturoKiwi

Active Member
Joined
Feb 13, 2020
Messages
258
Likes
116
Are you sure that it is broken? Did you try to press the "C" button on the remote?
Because, if you accidentally press it, the remote stop working and you must press it again to return to work again
 

Roddy

Member
Joined
Oct 14, 2020
Messages
42
Likes
27
Are you sure that it is broken? Did you try to press the "C" button on the remote?
Because, if you accidentally press it, the remote stop working and you must press it again to return to work again
Thanks. That fixed it. Seems A, B and C change the frequency the remote works at. Also, the circle-arrow changes the input, and fn switches from headphone to speaker out. I say this because I'd been going through the menu for months, taking twice as long to do these things.
 

hjteq

New Member
Joined
Jul 28, 2019
Messages
1
Likes
0
Hello @Crohnic and all. Sorry for this late follow up but have been quite busy with assorted projects. We ended up purchasing a bricked SMSL M500 unit out of Australia and did manage to disassemble the unit for a review. Our unit was quite tight to remove the wedged stacked circuit boards but others have reported that the same pair of boards slid out fine. Perhaps just bad luck that almost needed soap to slide the boards out.

The 2 x flex ribbon cables are quite short and will be impossible to use again as supplied by the factory after the unit is disassembled. Others have reported the same concern - the ribbon cables must be replaced with a longer set.

We have studied the surface mount flash memory device which is a 8 pin SOIC package that is common to the industry. Initially thought to build a personal reflashing tool that the end user can clip onto the existing surface mount flash device. This piggy back tool is common in the electronics industry. This clip on + ground + another wire to force the circuit board into RESET mode (ie. RESET line = GROUND will allow for the onboard XMOS CPU to release the lines that are linked to the flash memory device). After this setup, the external flash programmer can erase / program & verify the new firmware. The same tool could be used to restore the flash memory anytime in the future..no more bricking.

Technically, the firmware is held inside a SPI flash memory device that is very common and from Winbond Semiconductor. Using the above setup, an external SPI bus master can come along and communicate with the SPI flash memory device to erase / program / verify the contents - just like the factory did. They performed the same task out-of-circuit and soldered in the ready to use flash memory during the pcb assembly process. We had hoped that some contacts / connectors would be exposed to quickly perform this hardware fix. None have been found.

However, believe the above is not practical since it may be a one-time use tool. While we can build such a device, it may not have much value and can be difficult to use with the spring clips + ground wire + RESET probe wire. Too many contacts to correct the firmware while the flash memory chip that is bricked onboard. There is also an AC to DC power supply which we wish to not have the end user be exposed to due to risk of a shock.

Plan B is what a number of other SMSL M500 owners have already done - believe they have been mainly in Europe and Russia. That is, to use a hot air tool to carefully desolder the same flash memory -> insert the flash memory device into an external programmer (about $20 on Amazon USA; about $10 USD on Aliexpress) -> reflash the contents -> solder the chip back. Rebuild the unit using longer flex cables as the original ones are far too short.

This method is confirmed to be working.

We have invested a number of hours to see if we can communicate with the box over the USB and what is left of the DFU interface and Windows programming. So far, no luck on this approach to fix the box. Ideally would have been the best solution. Still not done with this research but not looking very positive.

Plan C may be worth a consideration and that is for us to ship to you a kit of a pre-programmed surface mount device (2.06 firmware) + the longer flex cables. Then you can take your unit to a local cell phone repair shop - just ask in advance if they are confident to "remove a surface mount 8 pin SOIC device and replace with another" - estimating that the procedure to dismantle the unit and perform this task and put back together is 1-2 hours at most. You may even wish to carefully dismantle the unit yourself and bring in the stacked board to the shop and respectively, you can rebuild the unit after this operation. A quality cell phone / computer repair shop will find this to be a breeze to replace the single component. We perform low level repairs on macbooks / ipads, etc. daily on much much smaller components.

Plan D is to send the unit to us and we can do the same -> perform the above task and return back to you. We are in Windsor, Ontario so it may make sense to those who are nearby. Best solution is to apply the new smd flash device locally for the least downtime.

To readers who are outside of North America, you may want to consider to purchase the programmer tool that a few have done already. We can document this procedure but highly recommend that the removal and resoldering of the flash memory be handled by a qualified repair shop.

The firmware is encrypted and respectively took a bit to have the SMSL factory release the binary dump to us of the flash memory. In summary, the corrupt memory device needs to be erased -> programmed -> verified or replace with the same device but with the 2.06 firmware.

Moving forward, this issue should not surface again since you will be on the working firmware and the factory has stated that they will not have this quirk on future releases of the firmware.

Feel free to share your feedback and we can gather up more details on the unit and post here for public access. Need to review a fair cost to both parties for the kit and if you would like for us to perform this service. We do have very good ship rates from us in Canada to the USA with 2-day Fedex delivery but unfortunately not the same relationship for incoming parcels. Believe that all together, the costs have to be lower than shipping back to China.

Thanks.
So that Plan D you have there. Do you have the details figured out? Shipping address, fair price for labor?
 

Blew

Active Member
Joined
Jul 24, 2020
Messages
178
Likes
62
Location
Sydney, Australia

Lupin

Addicted to Fun and Learning
Joined
Feb 11, 2021
Messages
575
Likes
961
Any idea what it improves on? Don't suppose it fixes the 3rd harmonic issue?
No it doesn't because it can't. The Xmos driver only facilitates the communication between the host (usually computer) and the M500.

The M500 has two firmwares. One for the Xmos USB interface and one for the actual DAC. The Xmos is easily updated with a firmware you can download and then flash to the interface from your PC.
However you can't update the actual DAC firmware this way because the Xmos interface and therefore your PC doesn't have access to it.
That's why owners have to most likely return the unit as the actual DAC firmware is not flashable without completely taking the unit apart and then I'm not even sure there is a connector like on the SU-9.

That's also the reason why I don't get all excited about new Xmos drivers.
It won't change or gain anything unless you have connection/stability issues.

Unlike what you read in places like Head Fi Xmos drivers can not and will not change/improve the way the DAC sounds because it simply can't. The sound is created in the DAC, the part Xmos doesn't have access to.
 

seki97

Member
Joined
Apr 21, 2021
Messages
8
Likes
3
Hi guys, I'm having trouble playing dsd512 files, foobar says "Unrecoverable playback error: Sample rate of 1411200 Hz not supported by this device", while dsd256 files do work fine, and it shows dsd on the smsl display.
I have sw 1.7 and hw 1.3, maybe I should upgrade the firmware, how can I do? USB drivers are currently up to date on my windows pc
 

Veri

Master Contributor
Joined
Feb 6, 2018
Messages
9,596
Likes
12,036
yes I have this latest version
Then it should really work.. hmm. Are you using ASIO or WASAPI to push the stream to your DAC, have you tried both?

https://diyaudioheaven.wordpress.co...-part-3-new-experimental-sacd-plugin-v-0-9-x/ try this guide. I know if you use a wrong (too high) version it can only send DSD as DoP instead of native, so then it will try to send the DSD512 encapsulated which requires double (DSD1024) the data rate which is not supported by this DAC.
 

seki97

Member
Joined
Apr 21, 2021
Messages
8
Likes
3
Then it should really work.. hmm. Are you using ASIO or WASAPI to push the stream to your DAC, have you tried both?

https://diyaudioheaven.wordpress.co...-part-3-new-experimental-sacd-plugin-v-0-9-x/ try this guide. I know if you use a wrong (too high) version it can only send DSD as DoP instead of native, so then it will try to send the DSD512 encapsulated which requires double (DSD1024) the data rate which is not supported by this DAC.

Thank you, it wasn't easy but now it works! I followed the guide and "Mode 2: Bitperfect outputting native DSD through DSDTranscoder" actually worked! Mode 1 didn't.
 

jdoe

Member
Joined
Sep 5, 2020
Messages
43
Likes
40
Alright, finally I got some time to fix 3rd harmonics issue. Here you can find instruction and resources to do the same fix for M500.

Couple months ago I got M500_Firmware_Fix.zip alongside with Unknown_1.6_Firmware.hex files from SMSL-Mandy, thou he didn't want to send any JTAG\SWD flash tool and I had to investigate the whole process on my own. (Quick note, please do not use M500右 1v6.hex, because in my case it makes M500 non-bootable).

Inside of the zip file you can find M500 Update Instructions_EN_.pdf, which says that M500 uses STM32F103VE chip. I've disassembled the unit and confirmed, that chip is indeed marked as STM32F103VE, so I've grabbed STM32F103xE Datasheet and started to look for JTAG\SWD pins. By measuring chip size and number of connection pins I found that M500 uses LQFP100 14×14 mm STM32F103xE package. Documentation confirms that JTAG/SWD is available for this chip:
SWD-DOC.png


Quick document review allows to find SWDIO and SWCLK pin names:

JTAG-PINS.png


SWDIO is PA13 and SWCLK is PA14. Here they are:
CHIP-PINS.png


Directly attaching wires to the chip is a very tricky process and requires some soldering skills, however on the back side of the M500 board (one, which is responsible for the digital processing) we can find JTAG control points, they allow to easily solder wires. Before actual wire solder process I had to ring-out JTAG points to the chip pins, here is screenshot of already connected setup which utilizes Raspberry PI 3:
RPI-CONNECT.jpg

NOTE: M500 should NOT be powered on by default power cable. Just disconnect everything.
On Raspberry PI GPIO I've used pins #1 for +3.3, #9 for GND, #18 as GPIO 24 for SWDIO and #22 as GPIO 25 for SWCLK, here is diagram:

RPI-PINS.png


SPI should be enabled on RaspberryPI. Next we need to install following packages on RPI side:

Bash:
sudo apt-get install git autoconf libtool make pkg-config libusb-1.0-0 libusb-1.0-0-dev

Then clone and build OpenOCD:

Bash:
cd ~
git clone https://github.com/lupyuen/openocd-spi
cd openocd-spi
./bootstrap
./configure --enable-sysfsgpio --enable-bcm2835gpio --enable-cmsis-dap
make
sudo make install

There might be few missing libraries during OpenOCD build process, however it is quite easy to either install them via sudo apt-get install or just by building them from sources. I didn't remember which ones were missing on my RPI, but it took only few mins to resolve all missing libraries, it could be related to the fact, that I'm using DietPI on RPI, which is very lightweight and does not include a lot of software.

Next step is to add correct configuration file for the OpenOCD, here is mine (you need to put it to the /usr/local/share/openocd/scripts/interface/, filename could be raspberrypi3-native.cfg):

Code:
#
# Config for using Raspberry Pi's expansion header
#
# This is best used with a fast enough buffer but also
# is suitable for direct connection if the target voltage
# matches RPi's 3.3V and the cable is short enough.
#
# Do not forget the GND connection, pin 6 of the expansion header.
#

interface bcm2835gpio

bcm2835gpio_peripheral_base 0x3F000000

# Transition delay calculation: SPEED_COEFF/khz - SPEED_OFFSET
# These depend on system clock, calibrated for stock 12000MHz
# bcm2835gpio_speed SPEED_COEFF SPEED_OFFSET
bcm2835gpio_speed_coeffs 194938 48

# Each of the SWD lines need a gpio number set: swclk swdio
# Header pin numbers: 25 24
bcm2835gpio_swd_nums 25 24

transport select swd

set WORKAREASIZE 0x2000

adapter_khz 4000

source [find target/stm32f1x.cfg]
reset_config none

We need to convert bootloader file from .hex to .bin format, it can be done by installing JLink_V512e.exe from the zip file and running J-Flash tool. File->Open data file->Choose M500_for_HW1_2.hex or M500_for_HW1_3.hex (it is IMPORTANT to choose correct version for your M500, you can find it at M500 system menu, there you will see either HW1.2 or HW1.3). Next File->Save data file as...->and then choose "Binary file (*.bin)" type->provide new file name (for example M500_for_HW1_2.bin) and click Save button.

Copy newly converted bin file to the RPI (for example you can use WinSCP to connect and copy file, or just by placing it on USB stick).

Start OpenOCD with raspberrypi3-native.cfg file (see code above):

Bash:
sudo openocd -f <path to the raspberrypi3-native.cfg>
example:
sudo openocd -f /usr/local/share/openocd/scripts/interface/raspberrypi3-native.cfg

If everything is fine it should start listening on port 4444:

Info : Listening on port 4444 for telnet connections

Now you need to connect to it (please change ip address if you are running telnet from your PC instead of pi):

Code:
telnet 127.0.0.1 4444

Now it is time to enter some commands (you can find comprehensive guide at OpenOCD User’s Guide), but before it we need to confirm flash memory address and length:
MEMORY-MAP.png

So it starts at 0x08000000 and ends at 0x0807FFFF, which is 0x7FFFF total bytes long.

Lets take a current firmware backup first (NOTE: these are the commands, which are running in telnet session):

Bash:
halt
dump_image M500_original_flash_dump.bin 0x8000000 0x7FFFF
resume

I would recommend to save M500_original_flash_dump.bin somewhere else, just in case if new firmware would not work.
Now we can rewrite flash and verify it (you might need to provide full path to the *.bin file, in my case I put them in the same folder where I started openocd):

Code:
halt
flash write_image erase unlock M500_for_HW1_2.bin 0x8000000 bin
resume
halt
verify_image M500_for_HW1_2.bin 0x8000000 bin
resume

Hopefully there should be no errors. It is safe to shutdown RPI and assemble M500 (or you can power it on without case). Here is what I got:
P10918-072543.jpg

New firmware is 1.7 and date is 2020-5-30, which is the same, as in fixed factory devices. Also DPLL option is available now:
P10918-072511.jpg


As for the sound quality improvements I would say that both low and top ends are improved: bass goes deeper and highs are a bit more detailed.
I would be glad to answer any questions and guide other members how to fix their devices too.
 

jdoe

Member
Joined
Sep 5, 2020
Messages
43
Likes
40
Some time ago I've already fixed M500 issues related to the stuck XMOS device revision (see https://www.xcore.com/viewtopic.php?p=38411#p38411). If anyone needs I can explain in a bit more details how to fix XMOS issue in a separate post.
It is not mandatory to use Raspberry PI for the whole process, you can use any JTAG/SWD programmer tool. I've used RPI because I didn't have any standalone tool, like https://www.ebay.com/itm/254181028177.
In case if someone is planning to use older or newer Raspberry (mine was Raspberry Pi 3 Model B+) please be careful with GPIO pins, order may be different. Make sure you are using +3.3V pin (NOT 5V). Also you might have to fix raspberrypi3-native.cfg items, like bcm2835gpio_peripheral_base 0x3F000000, bcm2835gpio_speed_coeffs 194938 48, bcm2835gpio_swd_nums 25 24.
 

overherz

Member
Joined
May 7, 2020
Messages
21
Likes
12
:rolleyes: to flash again ... it seems in 10 years I will have 10 programmers so that I can listen to music normally )))

ordered

ST-LINK-Stlink-ST-Link-V2-Mini-STM8-STM32.jpg_640x640.jpg
 
Top Bottom