Succ-U-Bus

[Ken Forgettable]

We have three problems:

1. The port problem.

So one possibility would be to open a MidiPort output at the beginning of execution before opening the output with java library, and keep them both opened, and send messages through them as requested. Don't know if that wil fix the problem but we could try

I'm pretty sure the MidiPort.open function will itself close the port first, to release any used resources (Java could mutex it I suppose).
This problem only affects Maple (or otherwise badly configured systems) so do we need to fix it at all?

2. The buffer problem as already discussed.
From my testing with Succ-U-Bus I am 99% sure that splitting the SysEx is best. You don't even have to change output buffer size in MidiOX for it to work.
I'll fiddle some more.

3. The comm's problem.

use MegaDrum USB directly the firmware update errors both with v3 and v4 bootloader. Seems strange.

The secure bootloaders are exclusively relying on the hardware error correction to communicate at all.
They are set up as synchronous slaves - but they have no clock line!

That last sentance was taken directly from Lenard Cohens' new album

[dmitri]

3. The comm's problem.

use MegaDrum USB directly the firmware update errors both with v3 and v4 bootloader. Seems strange.

The secure bootloaders are exclusively relying on the hardware error correction to communicate at all.
They are set up as synchronous slaves - but they have no clock line!

I tried it with Atmega32 where bootloader's USART has always been configured as asynchronous. Besides updating with V3/V4 works fine using MIDI-OX and also if it were the cause it would have also effected v1/v2 but it doesn't.

[Ken Forgettable]

More on the buffer thing - (Java MIDI Bug at page bottom) at http://www.ucapps.de/jsynthlib.html

[elrules]

Oh my god, although it says that in MacOSX it doesn´t happen, I found that this bug could explain the bad behaviour of MCT in Mac. In another thread I posted my testings. When you sent settings requests (short sysex messages) everything ok, then you send a bigger sysex and you cannot send again short ("load") messages. That makes sense with this known bug. I will make a test setting all sysex messages to a fixed amount of bytes, filling the buffer with 0x00 bytes if the sysex is shorter than maximum. Let´s see if Mac problem can be solved with that change.


On the other hand, if sysex messages can be splitted and sent with the default java library, we can stop using MidiPort library as the reason of using it was that with Java library you couldn't send big sysexs. I have to try

[Ken Forgettable]

FYI: More clues (nearly complete) and Microsfot bashing in this fun thread

[elrules]

The thread is pretty long, could you sum up the most important conclusions?

[Ken Forgettable]

Known USB SysEx transmission bugs.

+ Sun bugs
Where current SysEx is shorter than the previous it gets sent with the old
length (may or may not be fixed).

+ Microsfot bugs (not fixed for years)
"Class compliant" driver (USBaudio.sys) causes corruption in transmission
beginning at offset 240 (0xF0 !). If buffer size > 240 then data loss may
also occur.

Known USB SysEx transmission error workarounds.

For the Sun bug:
Humm, see below.

For the Microsfot bug:
+ Use a non-MS USB driver eg. Roland, Yamaha.

+ Route through MidiYoke/MidiOX:
They address the bug thus:
Using a buffer bigger than the message.

Making sure Delay after F7 is checked.
(Used to force a buffer change on multiple small messages rather than
introduce the delay).

Using contiguous unpaged buffers in low memory - HeapAlloc()...


Techno babble suggestions for MCT
As far as I can tell there is no workaround for MidiPort as it uses the
'boilerplate' interface to USBaudio.sys but
+ Rewrite MidiPort to use HeapAlloc()?

+ Try using byteArray() class which is the nearest thing (?) to HeapAlloc()?

As the MIDI spec' allows for multiple buffers
+ Use small always full, fixed sized buffers.

When sending the FW SysEx, the final buffer may need padding. As the
bootloader will discard non-data Intel hex records (including the CRC) I
suggest we can just modify the final 'end of file record' by inserting zeros
to pad the buffer up to the last byte (which is always, end of SysEx == 0xF7),
and ammend the data-byte count (the first two characters after the colon)

Eg. If the last 'end of file record' line in FW.hex is

:00000001FF

If we need 19 (0x13) extra bytes (p) it becomes

:1300001ppppppppppppppppppppppppppppppppppppppFF

[Ken Forgettable]

1. When I configure MCT to use MegaDrum USB directly the firmware update errors both with v3 and v4 bootloader.)

To be clear; MCT (with split SysEx) works ok with v3 bootloader if you route it through MidiYoke/MidiOX first?

[dmitri]

1. When I configure MCT to use MegaDrum USB directly the firmware update errors both with v3 and v4 bootloader.)

To be clear; MCT (with split SysEx) works ok with v3 bootloader if you route it through MidiYoke/MidiOX first?

Yes.

1. When I configure MCT to use MIDI Yoke ports and do MIDI routing in MIDI-OX the firmware update using v3 bootloader the update goes smoothly both with a split and and single Sysex.

[elrules]

Ey guys, I was solving an issue that user Glamplitude had with MCT, and he accidentally discovered a way to update Megadrum firmware with windows xp, and an v3 bootloader, all using MCT. This is what he did:

1) boot XP
2) switch on the MD
3) load MCT
4) say "No" to "do you want to upgrade firmware"
5) open Options->Configuration in MCT
6) make sure that all the settings are compliant, also set Bootloader to v2
7) Click Firmware->Update firmware in MCT
8) switch off MD, then reboot holding down left button
9) MD said "waiting for SysEx"
10) open the file "erase_firmware.syx"
11) MD said "ERASED"
12) pressed OK in MCT dialog
13) Click Firmware->Update firmware in MCT again
14) open the file "megadrum32_16_32_20090705.syx"
15) MCT said "sending firmware", MD flashed MIDI LED
16) MD said something like "upgraded", or "updated" or something
17) MD rebooted
18) MCT did NOT detect any change, so I quit MCT and started it again
19) MCT said Firmware is up-to-date

So, the solution is so obvious that it makes me feel silly for not having thought about it before. MCT could send the erase sysex AND the firmware through the MidiPort interface, instead of sending the erase sysex through java and the firmware through MidiPort.