search

STMicroelectronics / STM32CubeWL

STM32Cube MCU Full FW Package for the STM32WL series - (HAL + LL Drivers, CMSIS Core, CMSIS Device, MW libraries plus a set of Projects running on boards provided by ST (Nucleo boards)
Other
107 stars 54 forks source link

SBSFU doesn't support correct YMODEM protocol #15

Closed honestech74 closed 2 years ago

honestech74 commented 3 years ago

I have worked in 1_Image_BFU for STM32WL55xx and tested it in Linux minicom. Your sample says it should be used 128B packets to send a firmware file on Linux minicom, but I couldn't see it's working. Eventually minicom is using sb -vv of lrzsz for YMODEM. I thought sb -vv -k will be same like Tera Term on Windows. The option -k means 1KB packet. So I decided to use 1K packets on Linux. There was an issue in SBSFU project (exactly in function SFU_COM_YMODEM_DataPktRxCpltCallback in sfu_com_loader.c) when using this YMODEM protocol. You are counting the packets by 1KB, but YMODEM can send 128B packet to avoid the large padding for last 1KB packet.

You can read this in Chapter 1.2 YMODEM minimum requirements in YMODEM protocol reference + The receiving program must accept any mixture of 128 and 1024 byte blocks within each file it receives. Sending programs may arbitrarily switch between 1024 and 128 byte blocks.

Also mentioned in wikipedia 1024-byte packets had been introduced in XMODEM-1k. This version did not change the trigger character from the receiver, so there was no way for the sender to know whether the receiver supported larger packets. Instead, XMODEM-1k was presented as a separate protocol on both ends of the connection. When such a connection was started, the sender could choose to send either 1024 bytes in a packet or 128, indicating the larger with an STX character in the header rather than the normal SOH. Normally only the last few packets would use the smaller packets, to avoid sending large amounts of padding. 1k also assumed CRC for all connections. YAM supported 1k with no changes.

So I had to count the received bytes for the file, not packets, and then it worked well. This might help someone who is using standard YMODEM without changing your sample code. :)

RKOUSTM commented 3 years ago

Hi @honestech74,

Thank you for your contribution. Your report will be forwarded to our development team. We will get back to you as soon as we have more details.

Thank you once more for this contribution.

With regards,

RKOUSTM commented 3 years ago

ST Internal Reference: 110582

RKOUSTM commented 2 years ago

Hi @honestech74,

Thank you for your report. According to our technical team, the SBSFU support the YMODEM on Windows with Teraterm. Actually, there is no plan to enhance the YMODEM and be compatible with MINICOM. Please allow me to redirect you to this thread of discussion on the ST Community.

I hope the link I provided you with was helpful. Thank you again for your report. We are looking forward to reading from you again.

With regards,

CodeOn-ArK commented 2 years ago

I have worked in 1_Image_BFU for STM32WL55xx and tested it in Linux minicom. Your sample says it should be used 128B packets to send a firmware file on Linux minicom, but I couldn't see it's working. Eventually minicom is using sb -vv of lrzsz for YMODEM. I thought sb -vv -k will be same like Tera Term on Windows. The option -k means 1KB packet. So I decided to use 1K packets on Linux. There was an issue in SBSFU project (exactly in function SFU_COM_YMODEM_DataPktRxCpltCallback in sfu_com_loader.c) when using this YMODEM protocol. You are counting the packets by 1KB, but YMODEM can send 128B packet to avoid the large padding for last 1KB packet.

You can read this in Chapter 1.2 YMODEM minimum requirements in YMODEM protocol reference + The receiving program must accept any mixture of 128 and 1024 byte blocks within each file it receives. Sending programs may arbitrarily switch between 1024 and 128 byte blocks.

Also mentioned in wikipedia 1024-byte packets had been introduced in XMODEM-1k. This version did not change the trigger character from the receiver, so there was no way for the sender to know whether the receiver supported larger packets. Instead, XMODEM-1k was presented as a separate protocol on both ends of the connection. When such a connection was started, the sender could choose to send either 1024 bytes in a packet or 128, indicating the larger with an STX character in the header rather than the normal SOH. Normally only the last few packets would use the smaller packets, to avoid sending large amounts of padding. 1k also assumed CRC for all connections. YAM supported 1k with no changes.

So I had to count the received bytes for the file, not packets, and then it worked well. This might help someone who is using standard YMODEM without changing your sample code. :)

Hello! Is it possible to update the board by using another microcontroller, while the SBSFU is already enabled.