Regression in X-CUBE-SBSFU v2 (YModem)

[Silvio Barani]

Posted on May 20, 2018 at 18:52

Hi.

Y-modem serial transmission in X-CUBE-SBSFU 2.0.0 is not working with CP2102 and FTDI232R Virtual COM chips.

It worked with version 1.0.0 of X-CUBE-SBSFUWith default ST-Link Virtual COM port device it is working fine with both versions.

The difference between ST-Link Virtual COM and mentioned chips is that two initial y-modem header packets sent from PC app. are buffered and visible as glued together on serial wire.

On ST-Link serial wire output there is small space visible between two header packets.YModem in v2 version tries to 'ack' immediately after receiving first packet while there is transmission ongoing - this is generating faulty response and finally transmission is broken.

While working with ST-Link serial port there is mentioned gap between packets and 'ack' is successfully sent.

In v1 there was 1s delay introduced in before header 'ack' reply so it worked fine also with glued packets.

Restoring this delay results in FTDI and CP2102 working with v2. However I don't know what was the reason to remove this delay so it could be problematic in other areas.

Potential fix is to restore v1 code:

For SFU:

File: sfu_loader.c Function: SFU_COM_YMODEM_HeaderPktRxCpltCallback

Add:

 /* NOTE : delay inserted for Ymodem protocol*/  HAL_Delay(1000U);

before return;

For Application:

File: fw_update_app.cFunction: Ymodem_HeaderPktRxCpltCallback

Add:

 /* NOTE : delay inserted for Ymodem protocol*/  HAL_Delay(1000U);

before return;

Dear SBSFU team - I'm so glad with v2 updates, but looking forward to v2.0.1

Regards

Silvio

[Tim Campbell]

Posted on June 01, 2018 at 14:11

We have SBSFU working well on the NUCLEO-L476RG, and it's great.

We are using IAR EWARM 8.22.   All is fine provided we are using the 

NUCLEO-L476RG.

We have tried to port the package to a P-L496G-CELL02. 

We changed a the processor type in the project, and everything built fine.  

It installed and appeared to run fine, with console messages indicating that the secure engine was initialised correctly, and SBSFU then tried to receive firmware via YMODEM. 

At this point, things failed.  No YMODEM packets were transferred.  Maybe there are some differences in the comms hardware between the two boards.

My question is, in future is there a plan to add support for SBSFU to STM32CubeMX, like the image below, to simplify the setup?

Thanks

Tim

[Silvio Barani]

Posted on June 04, 2018 at 15:51

Hi Tim. Thank you for reply.

I hope you'll manage to run Ymodem on P-L496G-CELL02.

Did you try Ymodem fix I mentioned before?

Regarding SBSFU support for STM32CubeMX:

I think there are two types of packages required: SBSFU_bootloader and SBSFU_application.

SBSFU_application should be enabled for user applications.

It should update SystemInit() function with appropriate SCB->VTOR value. Currently it is manual process described in Figure 38 of UM2262 document.It could also maintain slot addresses in linker files.

SBSFU_bootloader should be enabled for user defined SBSFU bootloaders.

For selected project it should add necessary libraries, linker definitions, keys etc.This could really simplify process of creating own SBSFUs bootloaders.

Best wishes

[Tim Campbell]

Posted on June 05, 2018 at 12:43

Hi Silvio

We got YMODEM working once we set the right pin for the UART RX line! The RX pin is different on the P-L496G-CELL02.  Rookie mistake. 

Mods to the file sfu_low_level.h are below:

♯ define SFU_UART_RX_AF GPIO_AF7_USART2

// ♯ define SFU_UART_RX_GPIO_PORT GPIOA// ♯ define SFU_UART_RX_PIN GPIO_PIN_3// ♯ define SFU_UART_RX_GPIO_CLK_ENABLE() __HAL_RCC_GPIOA_CLK_ENABLE()// ♯ define SFU_UART_RX_GPIO_CLK_DISABLE() __HAL_RCC_GPIOA_CLK_DISABLE()// mods for P-L496G-CELL0x ♯ define SFU_UART_RX_GPIO_PORT GPIOD ♯ define SFU_UART_RX_PIN GPIO_PIN_6 ♯ define SFU_UART_RX_GPIO_CLK_ENABLE() __HAL_RCC_GPIOD_CLK_ENABLE() ♯ define SFU_UART_RX_GPIO_CLK_DISABLE() __HAL_RCC_GPIOD_CLK_DISABLE()

The same changes also need to be applied to com.h in the UserApp

However, now the bootloader crashes shortly after starting the transfer.  I suspect the memory alignment needs to be different on this board, which is what I'm going to look at now.

[Tim Campbell]

Posted on June 05, 2018 at 17:32

We now have SBSFU working on a P-L496G-CELL02 board, just over the local ST_LINK uart for now.

The code changes in the previous post, to remap the RX pin in both the bootloader and the user app, did the trick.

The one difference I've noticed from SBSFU on the NUCLEO-L476RG board is that the UserApp does not come up if we unplug the board and plug it in again:  SBSFU does not find the UserApp, and the bootloader tries to download a UserApp via YMODEM. 

Pressing the reset button clears this fault and the board re-discovers the installed UserApp

[Amel NASRI]

Posted on June 06, 2018 at 15:27

Hi

Baranski.Sylwester

‌,

Please note that the regression issue you reported in your initial post is highlighted internally.

Hopefully the fix will be applied in next release as you expect it.

Campbell.Tim.002

‌, I am glad to know that you have already resolved your issue porting SBSFU to

P-L496G-CELL02 board. Your proposal to support SBSFU in STM32CubeMX is shared with relevant team as well.

-Amel

[Tim Campbell]

Posted on June 21, 2018 at 10:31

Hi Amel

Do you know when the next release of the SBSFU packager, and the STM32CubeMX add-on is planned?

We are planning a project around it, and it could save us some work if we could add support via STM32CubeMX 

Thanks!

Tim

[Silvio Barani]

Posted on June 28, 2018 at 13:58

Hi Amel.

Thank you in advance for the fix.

Unfortunately, I noticed also some SBSFU problems with L4+ (

https://community.st.com/0D50X00009XkWJqSAN

)

I would be grateful if the team could make an SBSFU example for NUCLEO-L4R5ZI board (SECBOOT_ECCDSA_WITH_AES128_CBC_SHA256 option)

Regards

Silvio.