MUFF WIGGLER Forum Index
 FAQ & Terms of UseFAQ & Terms Of Use   Wiggler RadioMW Radio   Muff Wiggler TwitterTwitter   Support the site @ PatreonPatreon 
 SearchSearch   RegisterSign up   Log inLog in 
WIGGLING 'LITE' IN GUEST MODE

Clouds Parasite v2.01: an alternative firmware for MI Clouds
MUFF WIGGLER Forum Index -> Eurorack Modules Goto page Previous  1, 2, 3, 4 ... 37, 38, 39  Next [all]
Author Clouds Parasite v2.01: an alternative firmware for MI Clouds
simonhold
sneak-thief wrote:
simonhold: With braids, a failed firmware update results in a blank screen. You have to reboot into firmware update mode.

What happens when you power off for 10 seconds, hold Freeze, then power on again?


Absolutely nothing.

I emailed Mutable Instruments. Fingers crossed he can give me a way to fix it myself or agrees to check the hardware. I mentioned your comment, mqtthiqs, of this happening before the new firmware was installed. Belgium isn't to far from France so I'm OK with the shipping costs if it will give back life to my beloved Clouds.
Funky40
simonhold wrote:

I emailed Mutable Instruments. .


i see here a delicate situation........
as mutable is nomore responsible when uploading custom firmware went wrong.


just posting this in regards that this situation probably should be discussed by the geeks who could help out other than olivier.
its great that mutable is open source.
Its supergreat that you guys are coding !!!
.....but probably some more communcication and organisation for such cases as above is due ?
"i think" it would be great if you guys who code also can take that load of faulty update situations........

i agree, on the not enough info on the manual in regards to updates.
detailed descriptions how a specific MI module is confirming the update procedure is not only VERY welcome, ....it should not be missed i think.

just a spontaneous thought...........
REVIVER
No issues loading the v0.95beta.

Running through some patches right now.....seems A-OK!
bennelong.bicyclist
In the Bees-in-the-Trees installation instructions, I clearly point out that Olivier does not offer an unbricking service, and that I can only help on a best-effort basis, and that I am located in Australia. I also very strongly recommend that potential users of Bees install the factory firmware first, in part so that they have practiced the firmware update procedure with the official firmware, but mainly to ensure they can uninstall Bees successfully. And there are lots of warnings about installing the firmware being at the owners own risk. And finally, I spent several months working with about 20 very brave beta testers before I made the Bees firmware more widely available - it is important to proceed cautiously with this stuff.

Of course, none of that helps with the current situation. It should not be possible to overwrite the audio bootloader via an audio update, and thus re-powering the module with Freeze pressed should restart the bootloader. The fact that it doesn't suggests either that a) the module developed a hardware fault while you were uploading the firmware, or b) there is a bug in the audio bootloader code. Both seem unlikely, but unlikely things do happen. Olivier may be interested in investigating.

How were you feeding the audio firmware update signal into the module? What software and hardware were you playing the WAV file through?

Failing all that, and assuming no hardware fault with the module, you should be able to re-flash the firmware via the FTDI or JTAG/SWD ports. You'll need a small bit of adaptor hardware. FTDI is probably easiest: the adaptor needed should be under 15 euro. If you aren't able to do that yourself maybe someone in the city in which you live can help? But really, it isn't hard. We can provide detailed instructions if you want to try this.
mqtthiqs
Funky40 wrote:
i see here a delicate situation........

[...]

"i think" it would be great if you guys who code also can take that load of faulty update situations........


I was indeed very sorry for simonhold about this situation, but there are several reasons why I think taking more responsibility would be extremely unreasonable:

- First and foremost, there is the technical barrier. I am indeed "geek" enough to modify MI's source code, but I do *not* have the skills, the time nor the equipment to debug this kind of issue. As I said, I follow the exact same procedure you all do to update my own unit with new code, and if something would come to brick one of my modules, I would be stuck just as simonhold (well, actually I'd probably go buy the JTAG programmer, reprogram the unit and publish instructions of my findings). You also have to realize that a firmware mod like this one represent a tiny modification of the whole source code, and that I don't have perfect knowledge of the whole code, far from it. In the present case, the bootloader seems to be faulty, which I have no idea how it works and never touched: only Olivier really does. Hence my advice to contact him above.

- Second, there is the formal/legal responsibility associated with open source. All code is subject to the MIT licence, which explicitly mentions that it is provided "as is, without warranty of any kind". This is done to protect the authors which, generally and as I do, provide the software for free, giving the product of their own work to the community. There is a disclaimer about this on my web page, and the same kind on Mutated Mutables' page.

I hope this seems reasonable to you too smile
mqtthiqs
Now that I think about it, I remember now Olivier mentioning a few early prototypes with a bug preventing updates (http://mutable-instruments.net/forum/discussion/comment/116340#Commen t_116340) Maybe this is what it is?
simonhold
bennelong.bicyclist wrote:
It should not be possible to overwrite the audio bootloader via an audio update, and thus re-powering the module with Freeze pressed should restart the bootloader. The fact that it doesn't suggests either that a) the module developed a hardware fault while you were uploading the firmware, or b) there is a bug in the audio bootloader code. Both seem unlikely, but unlikely things do happen. Olivier may be interested in investigating.

How were you feeding the audio firmware update signal into the module? What software and hardware were you playing the WAV file through?

Failing all that, and assuming no hardware fault with the module, you should be able to re-flash the firmware via the FTDI or JTAG/SWD ports. You'll need a small bit of adaptor hardware. FTDI is probably easiest: the adaptor needed should be under 15 euro. If you aren't able to do that yourself maybe someone in the city in which you live can help? But really, it isn't hard. We can provide detailed instructions if you want to try this.


Thanks for your informative response bennelong.bicyclist.

First to answer your questions. I was using Sony Soundforge Pro on my mac laptop with a Forusrite Scarlet 2i4 soundcard. I used a 6.35 mm (1⁄4 inch) (TRS) to 3.5 mm mono (TS) cable from output 1 straight to IN L on the Clouds with nothing else connected (not even in de rest of the case). I used both the headphone output on low volume as well as visual feedback from Soundforge Pro to confirm the audio firmware file played through to the end.

I agree with the notion that it should not be possible to overwrite the audio bootloader. But it seems that either you are right about it being a hardware fault or an audio bootloader bug, or it could be that Mutable Instruments doesn't separate the bootloader from the firmware.

In any case, for me the biggest hurdle and frustration is the lack of information regarding what is and what isn't supposed to happen. For instance, if you really are not supposed to power down the case after the procedure, but are supposed to wait for some kind of signal or indicator the manufacturers and the firmware modders should both inform people of this fact. "If {particular signal} doesn't occur: DO NOT POWER DOWN THE CASE BUT TRY AGAIN" for example.

I would love to have a step by step guide for uploading the firmware using a FTDI to USB connector. €15,- is not to much if it revives the module! Please send me the information in PM and email. And maybe on here too if I turn out not to be the only one with issues.

I'm not expecting any official reply from Mutable Instruments tonight so I'll just go sob in front of my comatose Clouds now...
mqtthiqs
simonhold wrote:
I'm not expecting any official reply from Mutable Instruments tonight so I'll just go sob in front of my comatose Clouds now...


waah If I lived in Belgium I would take you out for a beer. Keep us updated!
simonhold
mqtthiqs wrote:
Now that I think about it, I remember now Olivier mentioning a few early prototypes with a bug preventing updates (http://mutable-instruments.net/forum/discussion/comment/116340#Commen t_116340) Maybe this is what it is?


That could be the case, but I think it highly unlikely. Does Mutable sell their prototypes as part of their regular batches for stores? Mine was acquired through Schneider's.

Concerning the responsibility of open source modders/hackers I understand mqtthiqs' position. The person doing the mods can't offer full support as that person doesn't need to have full knowledge of how a fully operational 'regular' version works to create interesting variations.

I would also understand if Mutable doesn't want to help me if my module went dark after the update. But considering it did before the new firmware was actually in place, it still is a problem covered by the warranty.
simonhold
mqtthiqs wrote:
simonhold wrote:
I'm not expecting any official reply from Mutable Instruments tonight so I'll just go sob in front of my comatose Clouds now...


waah If I lived in Belgium I would take you out for a beer. Keep us updated!


Just got a reply, seems Olivier doesn't keep regular office hours either.
According to him pressing the Freeze button while powering up should always bring you back into firmware update mode. Guess I'll be sending a sick Clouds to Paris in the morning. sick
bennelong.bicyclist
simonhold wrote:

Thanks for your informative response bennelong.bicyclist.

First to answer your questions. I was using Sony Soundforge Pro on my mac laptop with a Forusrite Scarlet 2i4 soundcard. I used a 6.35 mm (1⁄4 inch) (TRS) to 3.5 mm mono (TS) cable from output 1 straight to IN L on the Clouds with nothing else connected (not even in de rest of the case). I used both the headphone output on low volume as well as visual feedback from Soundforge Pro to confirm the audio firmware file played through to the end.

I agree with the notion that it should not be possible to overwrite the audio bootloader. But it seems that either you are right about it being a hardware fault or an audio bootloader bug, or it could be that Mutable Instruments doesn't separate the bootloader from the firmware.

In any case, for me the biggest hurdle and frustration is the lack of information regarding what is and what isn't supposed to happen. For instance, if you really are not supposed to power down the case after the procedure, but are supposed to wait for some kind of signal or indicator the manufacturers and the firmware modders should both inform people of this fact. "If {particular signal} doesn't occur: DO NOT POWER DOWN THE CASE BUT TRY AGAIN" for example.

I would love to have a step by step guide for uploading the firmware using a FTDI to USB connector. €15,- is not to much if it revives the module! Please send me the information in PM and email. And maybe on here too if I turn out not to be the only one with issues.

I'm not expecting any official reply from Mutable Instruments tonight so I'll just go sob in front of my comatose Clouds now...


Your audio update procedure sounds like it is OK. After a successful update, the module should reboot automatically and just come to life. If the update fails, as the instructions in the manual state, just press Freeze to start again. However, even if you power down, you should be able to just restart the audio battledore by powering on again with Freeze pressed. As has been stated repeatedly, it is very strange that this doesn't work, and that the audio bootloader has somehow been over-written. However, Olivier has very carefully designed the bootloader to be failsafe, and it is definitely stored in a separate area in the flash memory from the main program code.

The steps for reflashing via FTDI are on this page: http://mutable-instruments.net/modules/clouds/open I recommend that you use the FTDI Friend device recommended by Olivier on that page, but be aware that you need to cut some traces and solder some bridges to change it to work at the 3.3V levels required by Braids. Others may be able to recommend alternative FTDI adaptors that don't require soldering if that is a problem.

What sort of computer do you have? I'm hoping it is a Mac or a linux, but I bet it isn't. If it is Windows, then others may need to help with detailed instructions - I only have Mac OS X and Linux computers.

Anyway, let us know what Olivier says.

Edit: ah OK, he confirms what we are saying here. I suspect he is quite curious to see whether the audio bootloader has somehow been over-written, or whether it is a hardware fault. Pretty amazing customer service, I'd say.
pichenettes
Unless you are explicitly told you got one (and you paid one third of what it actually cost me), your module is NOT a prototype.

I have updated the online manual to mention that the module reboots automatically at the end of the procedure.

I can think of very rare situations in which the firmware upgrade procedure could start but would fail at a later point in the audio file. I can't think of a way a failed firmware upgrade would damage the module - at the very worst it should still boot in firmware upgrade mode. That's why there is no uppercase warnings in the manual. I'll know more once I see the module, the only weird case I've seen so far was a guy with an overloaded PSU causing 60 Hz bleed in the ADC, causing the update procedure to fail immediately even when no audio signal was sent.

Quote:
Olivier doesn't keep regular office hours either.


I do, usually 12 hours a day, 6 or 7 days a week. "Unfortunately" I took my first day of vacations this year. I would be in a much, much better place if people didn't expect me to do that.
bennelong.bicyclist
pichenettes wrote:

Quote:
Olivier doesn't keep regular office hours either.


I do, usually 12 hours a day, 6 or 7 days a week. "Unfortunately" I took my first day of vacations this year. I would be in a much, much better place if people didn't expect me to do that.


Do you mean it would be better if people didn't expect you to work 12 hours per day, 6 or 7 days per week? Or didn't expect you to take holidays?

Personally I dread the prospect of holidays and resent having to prepare for them and stop what I am currently doing, but then I always really enjoy them once they have started and in retrospect I am always glad I took a break to travel somewhere else, and spend some time outdoors.
simonhold
pichenettes wrote:
Unless you are explicitly told you got one (and you paid one third of what it actually cost me), your module is NOT a prototype.

I have updated the online manual to mention that the module reboots automatically at the end of the procedure.


That's what I thought about the prototype series!

And thank you very much for the addition to the manual. It means a lot I think to users to be more certain about what is going on when handling their gear.

My module is in the mail and will be visiting Olivier in Paris shortly. I sincerely hope a resuscitation is possible.
mqtthiqs
Ok guys, I got bitten just like simonhold very frustrating I just bricked my clouds updating it (all four LEDs are orange, audio is silent and I can't access the bootloader to update again).

I strongly suggest that everyone stop updating their firmwares until more is known from simonhold's unit. There is clearly a rare situation where updating makes the module unusable and further updates impossible. Let's hope this will be solved easily so we can continue hacking and modding soon!
cbeefheartuk
I had the same thing on mine - the lights all lit orange and wouldn't take any update after trying to load the parasite version and something going wrong.
On mine if I then unplugged the lead to the INPUT and turned it back on it seemed like it was OK I think but plugging a lead back in from my laptop caused all lights to go on again and it would do nothing.
What had happened is sending the update possibly too loud seemed to have damaged the Doepfer mini jack cable going from my laptop soundcard to the Clouds input and swapping that let it work again.
I thought it was dead for quite a while so it was quite relief.
Probably nothing to do with what you said but was what happened on mine so something to check maybe if anyone does have a problem.
sneak-thief
cbeefheartuk wrote:
What had happened is sending the update possibly too loud seemed to have damaged the Doepfer mini jack cable going from my laptop soundcard to the Clouds input


What you described simply isn't electrically possible given the maximum voltage and current from any given audio interface.
mig27
mqtthiqs and simonhold please keep us updated.
I'd really like to give the new reverb mode a whirl but right now it seems a tad unsafe.

Keeping my fingers crossed for you guys!
REVIVER
Is there any risk for those who have already successfully updated to v0.95 beta? As long as we don't try to update again?

How about reverting back to original Clouds firmware?

I have 2 Clouds units with v0.95beta on both and they seem to work fine right now, but this has me a little spooked.
mqtthiqs
From what we know, the bootloader is the most probable culprit. Which means that any firmware updates may be risky, so avoid them. So I would advise to stay on v0.95beta and not downgrade to the original firmware. This is not much more than an intuition though, I can't tell you better before we understand what's really going on.
mqtthiqs
Just to keep you guys updated... I revived my Clouds today in 5 minutes with the help of a little 15$ FTDI cable. So, at least there seems to be nothing irreversible in this bootloader bug. w00t

I found no easy way to investigate further what had happened, so I have no new info on what's causing the problem.. only that it's easily curable!

If anyone happens to have a bricked Clouds in Montreal, I'll be happy to provide de-bricking help now that I can.
rupertlally
Pleased to hear you got yours working again Matthias. Is it just a question of sending the module the firmware via the mini JAG connector with the FTDI cable (you're talking to a Luddite here)?

Still haven't found any further bugs using 0.95 beta btw, seems pretty solid to me...
rupertlally
Btw cbeefheartuk 's comment intrigued me - and once again forgive my Luddite brain here - as the input gain is analog, is it possible that increasing the gain too much and distorting the audio signal would make the unit think the bootloader code is corrupted? In every other module (Braids, Tides) the firmware is loaded through a digital input...

Once again, apologies if I clearly talking rubbish and don't realize it...
bennelong.bicyclist
rupertlally wrote:
Pleased to hear you got yours working again Matthias. Is it just a question of sending the module the firmware via the mini JAG connector with the FTDI cable (you're talking to a Luddite here)?

Still haven't found any further bugs using 0.95 beta btw, seems pretty solid to me...


Basically you need to follow the instructions provided by Olivier here: http://mutable-instruments.net/modules/clouds/open

You can use either the FTDI serial port, which is the 6 pin connector, with an FTDI adaptor, or the miniJTAG port (2x5 pins) with a JTAG or SWD adaptor. The FTDI approach is probably easier and cheaper.
bennelong.bicyclist
rupertlally wrote:
Btw cbeefheartuk 's comment intrigued me - and once again forgive my Luddite brain here - as the input gain is analog, is it possible that increasing the gain too much and distorting the audio signal would make the unit think the bootloader code is corrupted? In every other module (Braids, Tides) the firmware is loaded through a digital input...

Once again, apologies if I clearly talking rubbish and don't realize it...


No, the audio firmware update files are, um, audio-encoded - using QPSK encoding, like a dial-up modem or storing data on an audio cassette... (blank looks). And they are input via audio inputs e.g. the FM input on Braids. The audio file isn't the bootloader - the bootloader code is already on the module, and in theory, it can't be overwritten or corrupted by a failed audio firmware update. But it seems like something strange is going on with Clouds, and the bootloader may be being overwritten somehow. Anyway, no physical damage, and the modules are recoverable by re-flashing from scratch via FTDI or JTAG, it seems, which is re-assuring.
MUFF WIGGLER Forum Index -> Eurorack Modules Goto page Previous  1, 2, 3, 4 ... 37, 38, 39  Next [all]
Page 3 of 39
Powered by phpBB © phpBB Group