SBSFU 2.7.0 , unable to load firmware with YMODEM in linux (minicom)

[Javier1]

If this thread was not read only i would bring it to life again. @Jocelyn RICARD @EEdwa.1 @Bubbles @Arno1 @Denish_Ribadiya @cyril 

After succesfull compiling (NUCLEO-G474RE) SBSFU and uploading UserApp troguh (TERATERM) 

\en.x-cube-sbsfu-v2-7-0\STM32CubeExpansion_SBSFU_V2.7.0\Projects\NUCLEO-G474RE\Applications\2_Images

 

I decided time to do the same in linux, the issue is teraterm doesnt work for linux.

Trying to use minicom:
Adding the simbol for minicom special compilation and recompiling SBSFU

installing minicom

 sudo apt install minicom
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
The following additional packages will be installed:
 lrzsz

minicom uses by default YMODEM lrzsz implementation

The FW update is VERY SLOW (for only 24K) and ends up with incomplete

 

half update:

 

full update, it says incomplete:

 

and the SBSFU console says FW too big

====================================================================== 
= (C) COPYRIGHT 2017 STMicroelectronics = 
= = 
= Secure Boot and Secure Firmware Update = 
====================================================================== 
 
 
= [SBOOT] SECURE ENGINE INITIALIZATION SUCCESSFUL 
= [SBOOT] STATE: CHECK STATUS ON RESET 
 INFO: A Reboot has been triggered by a Hardware reset! 
= [SBOOT] STATE: CHECK NEW FIRMWARE TO DOWNLOAD 
= [SBOOT] STATE: CHECK USER FW STATUS 
 No valid FW found in the active slots nor new FW to be installed 
 Waiting for the local download to start... 
= [SBOOT] STATE: DOWNLOAD NEW USER FIRMWARE 
 File> Transfer> YMODEM> Send CCCCC 
 Fw too big 
= [SBOOT] STATE: HANDLE CRITICAL FAILURE 
= [SBOOT] STATE: REBOOT STATE MACHINE 
========= End of Execution ========== 

 

[Javier1]

Same if i use picocom with lrzsz library

 

[AScha.3]

What if using other terminal progs , like :

 PuTTY

see ->

https://alternativeto.net/software/tera-term/?platform=linux

 

[Javier1]

im more concern about what i am doing wrong because ST says the code supports miniCom.
ill try putty aswell thanks @AScha.3 

Edit, putty (plink) doesnt support YMODEM

[Javier1]

im trying again with my raspi forcing YMODE to use 1k block size
console1 opens the serial port:

minicom -b 115200 -D /dev/ttyACM0 

console2 uses the opened serial port:

sz -k --ymodem /media/greenUSB/UserApp.sfb > /dev/ttyACM0 < /dev/ttyACM0

 
result: are those garbage ACK errors?

Sending: UserApp.sfb
Ymodem sectors/kbytes sent: 1/ 0kRetry 0: NAK on sector
Retry 0: Got 49 for sector ACK
Retry 0: NAK on sector
Retry 0: Got 41 for sector ACK
Retry 0: NAK on sector
Retry 0: Got 4e for sector ACK
Retry 0: NAK on sector
Retry 0: Got 68 for sector ACK
Retry 0: NAK on sector
Retry 0: NAK on sector
Retry 0: Got 4f for sector ACK
Retry 0: NAK on sector
Retry 0: Got 55 for sector ACK
Retry 0: NAK on sector
Retry 0: Got 53 for sector ACK
Retry 0: NAK on sector
Retry 0: Got 48 for sector ACK
Retry 0: NAK on sector
Retry 0: Got 53 for sector ACK
Retry 0: NAK on sector
Retry 0: Retry Count Exceeded

Transfer incomplete

 

[Javier1]

Succesfull log files, from the same file  transmission with a loopback setup in a linux based PC picoCom+lzszr

minicom uses 128 size packets
seeing 2021 ticket https://github.com/STMicroelectronics/STM32CubeWL/issues/15
it looks like there is a bug and is not a priority of ST dev team

 

[Javier1]

Im cornering the "FW too big" problem to this line inside SFU_COM_YMODEM_DataPktRxCpltCallback()

 /* Check size to avoid writing beyond DWL image size */
 if ((m_uDwlAreaAddress + rx_size) > (m_uDwlAreaStart + m_uDwlImgSize))
 {
 m_LoaderStatus = SFU_LOADER_ERR_FW_LENGTH;
 e_ret_status = SFU_ERROR;
 }

 

m_uDwlAreaAddress = always 0x8048000
m_uDwlAreaStart = changes ?

rx_size is always 128 
m_uDwlImgSize = received image size by YMODE block 0 info,  (in my case 24704)

i believe the last packet being received is not expected?

[Pavel A.]

Yes, the old Ymodem code from ST examples is a bit crusty and could be tidied. Possibly they tested it against teraterm and it worked. For best results you can isolate the ymodem receiving (and/or sending) from writing flash, and debug/exercise against various terminal apps. When the ymodem part works well, add other ingredients.

/* This comes in the same line with my general advice to use Windows for maximum productivity and least distraction. A lot of folks hate this simple idea. I know. */

[Javier1]

---

@Pavel A. wrote:

/* This comes in the same line with my general advice to use Windows for maximum productivity and least distraction. A lot of folks hate this simple idea. I know. */

---

I dont hate the idea, is just the FW updates are comming from embedded linux boards

 

---

@Pavel A. wrote:

Yes, the old Ymodem code from ST examples is a bit crusty and could be tidied. Possibly they tested it against teraterm and it worked. For best results you can isolate the ymodem receiving (and/or sending) from writing flash, and debug/exercise against various terminal apps. When the ymodem part works well, add other ingredients.

---

The code is a mess, i think bisturi code isolation is going to be a pain, specially because all of this SBSFU SW disabling, today ill give it a go at touching it with a stick untill it works.

 

[Javier1]

Alright after two full days of untangling spaggeti.

The magic changes that make the SBSFU 2.7.0 , u FW update work with minicom  are: (only 128 bytes packet size)

To fix YMODEM transmission:

To fix the padding bytes mess from the FW update (128==SFU_COM_YMODEM_PACKET_SIZE)

If ST had this code in a public git repo i would create a bugfix report, but they dont .... :D , and they labeled the code as legacy and not supported.... release it to the community, come oon!

Kudos a @Pavel A. for the support

[Javier1]

AI answering questions and posting casino app SPAM , what a time to be alive .

 

the saddest part is that half of your comment makes sense