cancel
Showing results for 
Search instead for 
Did you mean: 

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

Jaanda
Associate II

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.

4 REPLIES 4

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 Venmo
Up vote any posts that you find helpful, it shows what's working..
Jaanda
Associate II

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
Associate II

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
Lead

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.