Skip to main content
Jaanda
Associate II
September 5, 2018
Question

Teraterm secure firmware update gets stuck after few kBs of transfer.

  • September 5, 2018
  • 4 replies
  • 1403 views

I am trying to port Secure bootloader project implemented for STM32L432KC Nucleo to my custom boards that use STM32L431VCIx. I have tested the example implementation on Nucleo by sending encrypted firmware via TeraTerm using Ymodem. This works. But the same implementation does not work on my custom board. I have made all the necessary hardware changes for UART peripherals, buttons etc. The Updater starts by sending around 4kB of data and then it does not go ahead. Any help in the right direction would be useful.

    This topic has been closed for replies.

    4 replies

    Tesla DeLorean
    Guru
    September 5, 2018

    Then you're going to have to analyze the interactions on the serial port.

    Check clocks and timing.

    Check USART state/status at the point communications stop.

    Tips, Buy me a coffee, or three.. PayPal VenmoUp vote any posts that you find helpful, it shows what's working..
    Jaanda
    JaandaAuthor
    Associate II
    September 7, 2018

    Update:

    I ported this code to our custom boards making necessary changes to peripherals(uart, leds, buttons etc.) and tried to update the firmware using UART(Ymodem). I tried two approaches.

    1.) Using the on-board stlink(uart com) to send encrypted firmware -> Here the firmware update stops abruptly after 4kb of data transfer. The update does not continue.

    2.) Using a third party USB-UART module -> Here the firmware update does not work and stops as well due to ymodem error.

    To confirm that my software porting was correct I loaded same firmwares on Nucleo and our custom boards. The firmware update works only on the Nucleo which has STLINK on it.

    Now I also broke off the stlink on one of the nucleo boards and tried to update firmware from a different nucleo(with stlink uart com). This is similar to our actual use case of updating firmware on custom boards. This did not work and shows same behavior as in step 1.

    I am suspecting this project has a dependency on on-board stlink and does not work with an external board.

    Jaanda
    JaandaAuthor
    Associate II
    October 10, 2018

    I have found a workaround to this issue. One needs to add a delay of say 10-100ms in the SFU_COM_YMODEM_Receive routine(case HAL_OK) depending on the USB-UART module you are using. It seems to be dependent on the buffering capability of the USB-UART module

    AvaTar
    Senior III
    October 10, 2018

    Check buffer sizes in the "Advanced" settings of the USB-to-Serial driver (Windows Hardware Manager, probably). Setting smaller buffer sizes and timeouts there will avoid timouts in attached components, like the STM32 board.

    In their default settings, Windows serial / USB-serial drivers use to push data on only if the FIFO / buffer is full.