Bootloader write function hanging during firmware upgrade.

[Gordon Madden]

Posted on July 29, 2017 at 01:32

I have a firmware upgrade app in C# that updates the firmware on a stm32f417IGT over USART.

It works on small upgrades �? original test files were about 13K �? but when I started testing the full firmware (200K), the host program would hang while executing the write command in the bootloader.

I added a delay in case the FIFO in Windows was getting full (64 bytes), but the host app still can't make it to the end of the 400K .HEX file. There is extra room in the .HEX file for firmware growth, with a CRC at the end of that 'partition'.

The write command will fail at different points, from 15K to 200K+ of the file completed.

Does anyone know why the write command would just stop like that?

I tried adding delay after the write, but that did not help.

Here is the section of C# code where it hangs:

      for ( int i = 0; i < length; i++ )

   {                  // Send individual characters to device

HANGS HERE-->

    _serialPort.Write(bytes, 4 + i, 1);            

                  // increment counter

                  byteCounter++;

     if( byteCounter % 32 == 0 )

     {         Thread.Sleep(40);     }

     // Add byte to checksum

     hexChecksum ^= bytes[4 + i];    // If counter == 256, reset counter, send checksum    if (byteCounter == 256)    {        sendAddress = true;        byteCounter = 0;

       // Convert checksum to a byte value and send

       hexChecksum = hexChecksum ^ 0xFF;       byte csByte = Convert.ToByte(hexChecksum);

       Byte[] csByte_arr = BitConverter.GetBytes(csByte);

       _serialPort.Write(csByte_arr, 0, 1);       // Receive ACK byte       byte_read = _serialPort.ReadByte();

       if (byte_read == NACK)

       {                 }     } // end IF byteCounter == 256

     //Console.WriteLine(byteCounter);

    } // end FOR loop

Thank you!

[Tesla DeLorean]

Posted on July 29, 2017 at 07:13

Not using C#, and also not having a problem sending more than 64 bytes at a time to a serial port.

Tend to use WriteFile, and catch situations where dwBytesWritten don't match the request,and resubmit the remainder.

Might want to instrument the loop, and watch for non ACK/NACK responses.

[Gordon Madden]

Posted on August 01, 2017 at 18:12

Is WriteFile an ST bootloader function or your own?

What does 'instrument the loop' mean?

Thanks!

[Tesla DeLorean]

Posted on August 01, 2017 at 19:27

CreateFile and WriteFile are Win32 API functions.

Instrument the loop, ie have it output progress and diagnostic information via debug console, or command line screen. Better understand the dynamics of the interactions with serial port, responses, etc. Do stuff that permits real-time debugging rather than breakpointing.

[Gordon Madden]

Posted on August 02, 2017 at 22:09

Oh, thanks!

Yes, I have a console version for testing that I originally wrote and then the 'forms' version that the client will use.

I have tried to catch a timeout exception as well. The Serial Port Write function in C♯ just stops working. I am getting ACKs on all packets of 256 bytes sent up to that point and have each transaction throughout the app print out checksums and ACKs.

Could it be a timing issue? Baud rate? Since it fails at different points in the writing of the upgrade, I find it hard to get any useful info from the failure.

[Tesla DeLorean]

Posted on August 03, 2017 at 05:42

Are using a USB-to-Serial adapter with a Prolific chipset? I've had bad experiences with their drivers at different times, and the current FTDI driver has been observed to cause my system to seize up randomly.