Just want to put this out there, C6 froze and crashed when I was updating firmware, now my Minitaur is bricked / locked up which Amos Gaynes (I guess the head chief when it comes to info on the Minitaur said should not happen, and his reasoning made sense which I’ll copy and paste below) but just in my opinion looking back I should of used MidiOX which in my opinion again is a lot more stable than C6 just not as straight forward. And yes I made sure the IDE looking ribbon cable was properly seated inside the Minitaur, and even tried holding down all 4 buttons (yes also using original power cable on a grounded power strip).
So here’s what I’d recommend and always been using, MidiOX. (I just used c6 because it came packed with the firmware update.)
http://www.midiox.com/
Here’s also a Mac alternative to C6
http://www.snoize.com
(never tried it before)
Amos Gaynes’s reason why C6 crashing shouldn’t have locked my Minitaur up which makes a lot of sense, not trying to scare people to update, Midi Sync sounds like a lotta fun get your mr oizo flat beat on, but you know clearly something went wrong. If I could go back in time I’d use MidiOX.
HI Graham,
The way the firmware update is supposed to work is as follows:
There are two sections of code memory in the Minitaur. One holds the bootloader, and the other holds the current firmware. When you turn on the power to the Minitaur, it always boots to the bootloader first. The bootloader’s job is to verify the integrity of the main firmware and then, if the main firmware passes its test, to boot to the main firmware. The bootloader is also responsible for handling firmware updates.
During a firmware update, you boot to the bootloader and erase the main firmware, but the bootloader itself is never touched or modified by this process. If there is any trouble with loading the main firmware, like an incomplete or corrupted file, then on the next power cycle the bootloader should detect that the firmware image is no good. It then erases the main firmware section and waits for new firmware to be sent. To a user, this should look like the beginning of the firmware update process where the unit sits with its GLIDE button LED blinking on and off, to indicate that the bootloader is waiting for new firmware.
In your case, all the button LEDs being lit solid and the unit not appearing as a USB device indicates that the processor is not running or is locked up. This shouldn’t be a state that it can get into in the normal course of what I described above. I’ve induced failed firmware updates all sorts of ways and the result is always that the broken firmware is erased and the bootloader waits for new firmware.
That’s why I’m speculating that a loose ribbon cable could be a possible culprit… I’d say it’s at least worth a quick check before shipping the unit back to Asheville NC, although we will certainly be glad to handle it that way if re-seating the ribbon cable doesn’t wake it up.
Regarding the internal JTAG port, yes that’s how code is originally loaded onto the unit at the factory, but it requires a special USB programmer to connect to it to load code from a computer and that hardware is on the expensive side. It’s not something I’d recommend that you invest in given that it’s our responsibility to get your hardware working again.
Thanks and kind regards,
Amos
OSX 10.14.6