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