Succ-U-Bus

[Rubis]

And I was just getting good with MIDI-OX, too.

[Ken Forgettable]

...MCT could send the erase sysex AND the firmware through the MidiPort interface ...

I've gone off MidiPort altogether

[elrules]

...MCT could send the erase sysex AND the firmware through the MidiPort interface ...

I've gone off MidiPort altogether

????

[Ken Forgettable]

...MCT could send the erase sysex AND the firmware through the MidiPort interface ...

I've gone off MidiPort altogether

????

Succ-U-Bus will read and checksum individual hex records - I'm hoping JAVA alone will cope with the smaller transfers.
Sorry it's taking sooo long...

[Ken Forgettable]

elrules,

* for windows users [cut] send erase sysex and firmware sysex through MidiPort

try the following all as one message (all in one MidiPort buffer)
+ SysEX_erase

+ 0xF7, 0xAA, 0x55, 0xAA, 0xF7

+ Firmware SysEx

...you have real hardware now!?

[Ken Forgettable]

Let's do it like this. MegaDrum users get MCT supporting firmware updates for "secure" and "secure+midi" bootloaders and I will add WDT reset to the MegaDrum firmware the same or next day.

2 months later...
This is not possible over USB - I have given up

[Ken Forgettable]

We have three problems:

1. The port problem.
2. The buffer problem as already discussed.
3. The comm's problem.(

I have identified a forth problem for which I can see no work around.

[Ken Forgettable]

Succ-U-Buss is at version 36!
Much time on the early versions were with whacky hardware errors. Around v25 I pulled the PIC and continued development via the std MIDI interface - C'est la vie.

Succ-U-Buss:
+ Does not need user (keyboard or LCD hardware).
+ Works with native Java under XP (no dll/JNI needed)
+ Requests correct firmware file name
+ Verifies comm's
+ Verifies flash
+ Can restart failed updates.

Testing with my v2.8 Synthex board:
+ AVRmega failed to flash @1/30 times (as good as or better than ponyprog).
+ USB comms works <50% of the time!

I have a scope on the USB and have observed 2 behaviours at failiure.
+ Occasional (strong) AC oscillation on the data lines or
+ No USB activity (PIC or PC) except for the AVR initiated data spikes.

For each failure, XP has had USB correctly enumerated.

Tested these by sending 0x99,38,1 from AVR firmware and had the PIC OR each third byte with 0x40. Recorded both streams. PIC failed badly - when it did communicate bad data, it always just buggered the high nibble of second byte (AVR USART buffering?)

Anyhow what could be *stopping* the normal USB signaling - is PIC is entering sleep and not waking up or what?

[elrules]

After 5 pages of thread I still have not ucking idea of what Succ-u-bus is

Could you explain without retorical words what is your project about?

[kurtus420]

seconded!!

After 5 pages of thread I still have not ucking idea of what Succ-u-bus is

Could you explain without retorical words what is your project about?