[sdiy] FW: Simple MIDI Seq for firmware updates

[Magnus Danielson]

MTG wrote:
>> Boot loaders are a bit tricky, you need to know the image is not 
>> corrupted
>> and need to be able to roll back to the original boot loader in the 
>> case of
>> a programming flaw, incomplete program update, memory corruption etc. A
>> simple way to do this using a protected (hardware write protection is 
>> best)
>> boot loader that is always in place, the system starts the boot loader 
>> runs
>> a checksum on the image and looks for an abort load signal of some 
>> sort. The
>> abort signal can be a jumper or other message. If there is no abort 
>> signal
>> received the loader executes the program.
> 
> Thanks for the good tips above and below.  I have a bootloader working 
> well over RS232, but for obvious reasons I don't want to have people 
> pull out a DB9 cable. Also, I don't really want to write a MIDI app of 
> my own at this time because that would be a steep hill to climb right 
> now (unless someone has a great Borland MIDI component). But I digress...
> 
>> Now using MIDI System Exclusives is not hard, and its function is open
>> ended.
>> For the handshake your target system can Send a System Exclusive message
>> block of its own. A MIDI receiver is also allowed to act as a MIDI
>> transmitter.
> 
> I don't think a handshake is possible if I use a SysEx loader like 
> MidiOx or a sequencer to play MID files.  Right?

You can avoid handshaking by a fairly simple variant of the above scheme:

Put a block number at the beginning of the blocks, and then let the last 
block have block 126. Say that you have 4 blocks, then they will be 
numbered 0, 1, 2 and 126. (assuming 7-bit data, you may vary your milage)

Now, the bootstrapper expects block 0 on start. If it receives block 0 
with OK checksum it stores away it and increment the expected block 
counter. If it receives block 126 correctly it will accept unless we 
have a resend-state it and increment the expected counter. When the 
expected counter is 127 we are done. The fun thing is what we do when a 
checksum fails, then we lit the red LED for "resend" and do not 
increment the expected counter. The user now needs to restart the 
transmission, and the boot-loader will dump all the blocks being higher 
and lower than the expected block and when it arrives it will checksum 
it and proceed if things was correct or not as above. If the checksum is 
correct, the resend state is removed (let the LED go orange).

You avoid handshaking, can use off the shelf programs for transmission 
and get a robust mechanism. If you trash your data, it will get very 
obvious since the number of restart attempts needs to go up.

Being able to display the block seen and block expected would be great 
hints when doing restart, as not starting from the top is allowed and 
will save time.

Cheers,
Magnus