I had a core with bootstrap 1.1b, mios 1.2, tc 1.1, ID = 0000000000000000, but i couldn’t sysex it anymore…
But if i send F0 00 00 7E 40 00 0F F7 i got F0 00 00 7E 40 00 0F 00 F7 back. Midi in and out seemed to work ok.
My sysex setting are 4* 2048, delay 750 after F7.
If i tried to overwrite the tc 1.1 app: nothing, no checksums, an automatic mios reboot, but the 1.1 app was still there.
Upload MIOS 1.3 during first 2 secs of startup: nada.
Now i burned a new pic with bootstrap 1.1b, id 0, and it just keeps sending F0 00 00 7E 40 00 01 F7 every 2 secs, even during upload of mios 1.3, and still no checksums…
But it did work before, so… what to do? :'(
I’ve read TK’s bootloader pages over and over again but am i forgetting something important?
Now i burned a new pic with bootstrap 1.1b, id 0, and it just keeps sending F0 00 00 7E 40 00 01 F7 every 2 secs, even during upload of mios 1.3, and still no checksums…
Correction: it gives F0 00 00 7E 40 00 01 F7 every 2 secs, but not during sysex.
I just tried with yet another pic and a new core: exactly the same… :-/
I guess that the download fails due to a feedback loop:
Ensure that the datastream from the MIDI In port is not forwarded to the MIDI Out port in order to avoid a feedback loop! Deselect the Auto-switch in the lower left corner before selecting a MIDI In/Out port so that this connection will not be done automatically. Check the port mapping at the right side: the MIDI In port should not appear in the list!
Are you sure that this isn’t a bug in the kx driver?
You can test it in the following way: create a “physical” loopback with a MIDI cable (direct connection from MIDI Out to MIDI In), open the SysEx tool of MIDI-Ox, load the .syx file and start Send/Receive SysEx.
If the number of received bytes doesn’t match with the number of transmitted bytes, you’ve a problem…
