Originally Posted By: peter
Originally Posted By: altman
Hmm, I mean there's nothing particularly special about the protocol (timing-wise) - the only time critical bit is interrupting the bootloader at the right moment.

ISTR there is no problem driving the erase commands (etc) interactively... which points to a problem with the upgrader code which is making it susceptible to differences? Does anyone have the code unzipped so they can post the relevant section?

The main difference in Mark's "USB-compatible" version seems to be that it buffers up the outgoing data and then sends it in one system call -- the stock download.c sends it a byte at a time.

The only theory I have as to how this could possibly make a difference, is if somehow the USB-to-serial adaptor can't saturate 115200bps transmit if it's only getting one byte per USB packet. (Perhaps, when driving it interactively, the terminal is line-buffered.) But actually I can't make the numbers for that add up, even for a USB-to-serial adaptor that's Low Speed 1.5Mbps.


It's definitely not a line buffered type thing; the bootloader will wait forever for the next byte (no timeouts). My guess is that my possibly overzealous flushing of input buffers in the upgrader so as I don't have to parse the echo from the bootloader is falling over. Nobody ever does flush the way I like it (which is: zero the head/tail pointer at that instant) - which tends to get replaced by "read with zero timeout until you see empty" which I can see getting seriously upset by USB.

With that in mind, can anyone nearer the code look? If not I will fire up gcc and compile it on my macbook, find a usb-serial adaptor, and see what happens wink

Hugo