C# and Xon/Xoff bootloaders

Go To Last Post
7 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi,

Maybe it's a bit off topic but think it may be useful for all interfacing C# and AVR.

For my AVR project I use bootloader that accepts HEX files on serial port. All this type of bootloaders use XON/XOFF protocol to synchronize flashing and data packets on serial link.

I wrote a piece of C# code to upgrade main program via serial port using HEX bootloader. This looks very simple (and it is) but unfortunately in my case it took some time to get C# program working.

The problem was c# completely ignored XON/XOFF characters. It just send all data without paying attention what AVR is doing.

I sent the hex file at once using only one call to Write() function:

serial.Write(AvrData, 0, AvrData.Length);

Before you copy this code I tell you: it does not work - XON/XOFF are ignored.

To get it working it must be replaced with:

for (int i = 0; i < AvrData.Length; i++)
{
  serial.Write(AvrData, i, 1); 
}

It this example XON/XOFF are processed properly.
I do not know whether it's a problem of C# component or windows serial driver. Maybe when the block of data is sent incoming data is not interpreted by the component responsible for handshaking.

And at the end, piece of code that sends hex file to bootloader:

        byte AvrData[] = System.IO.File.ReadAllBytes("myprog.hex");
        SerialPort serial = new SerialPort(SerialPortName, 19200, Parity.None, 8);
        serial.Handshake = Handshake.XOnXOff;
        serial.WriteTimeout = 1000;
        serial.Open();
        for (int i = 0; i < AvrData.Length; i++)
        {
            serial.Write(AvrData, i, 1); 
        }
        serial.Close();
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Loath though I am to stick up for C#, may I ask what makes you so sure that your AVR's bootloader is sending any flow-control in the first place? Can you connect a protocol analyzer to the RS232 link, and have it trigger on XOFF?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I used serial port monitor software and in addition simple command line copy file.hex com1: works with the bootloader.
Bootloader iteself is not an issue for sure.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

copy file.hex com1:

But the DOS copy command does not implement xon/xoff so the bootloader must presumably be going fast enough that it can receive a constant stream of bytes at the designated UART baud rate. (either that or the bootloader is implementing CTS/RTS in hardware which copy will respect)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:

But the DOS copy command does not implement xon/xoff

Of course it implements :-) (old good dos is not as bad as we all think).
But you must configure serial port first. The entire sequence should look like:

mode com1 baud=19200 DATA=8 PARITY=n STOP=1 XON=on
copy myprog.hex com1:
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

mogor wrote:
clawson wrote:

But the DOS copy command does not implement xon/xoff

Of course it implements :-) (old good dos is not as bad as we all think).
But you must configure serial port first. The entire sequence should look like:

mode com1 baud=19200 DATA=8 PARITY=n STOP=1 XON=on
copy myprog.hex com1:

Flow control is normally not handled by applications.
It is handled by the OS driver. That way all applications can benefit from flow control.

So yes, the copy command does not implement xon/xoff
but xon/xoff would still work assuming the com port driver implemented it and was told to use it
*and* more importantly the remote end also supports it and uses it.

--- bill

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The second version might just be slow enough for the other device to keep up :P (the .net serial library is not exactly a performer)

Joking aside, that seems perfectly plausible since one might need to make sure that an entire packet is sent before xoff breaks transmission. So I'd say you've hit an undocumented feature in the Win32 CommPort library.