HAL_Timeout issue from the application integrated to xcube SBSFU

[ANaga.2]

Hello people,

I am trying to integrate the xcube sbsfu feature to our application and everything went well but there is an issue while sending the .sfb via ymodem.

It starts downloading the firmware and after receiving 2 packets (4.9%), it stops downloading (see attached picture) and throws the below errors. 

-- -- !!Aborted by user!!

 -- !!Operation failed!!

When I debugged the code, I found the problem is coming from the below code

__HAL_UART_GET_FLAG(huart, Flag) ? SET : RESET

I guess the system is setting this to RESET and HAL_timeout is getting returned. May be because of huart->Instance->ISR or FLAG.

Could anyone please let me know what changes are required to successfully download the firmware on microcontroller (STM32L452).

Is this because of timer settings or timing mismatch?

Note :

1. I still have to figure out how to generate .sfb file for our application. For now, I am trying the download the .sfb from the example project (STM32L476RG)
2. I am using the sbsfu features of STM32L432KC and integrated them to our user application running on STM32L452. memory mappings are altered accordingly.

Thanks,

Ankush

[Jocelyn RICARD]

Hello Ankush,

it does not look like a timing issue as you could download first block.

Also, I guess you got the good debug traces.

I would suggest checking what happens in the loader when trying to write to flash for instance.

Especially the callbacks

SFU_COM_YMODEM_HeaderPktRxCpltCallback

SFU_COM_YMODEM_DataPktRxCpltCallback

in sfu_loader.c

Best regards

Jocelyn

[ANaga.2]

Hi Jocelyn,

Thanks for your response. This issue is solved now 🙂

We had set low priority for the thread which does downloading of package. After some time, uart was given to different threads of application which is why it was stopping. After changing the priority it worked.

Now, I am having issues with swapping of images. It is failing because SBSFU is failing to erase memory of 4kb in slot_0 while it is in the function eraseSlotIndex() during swapping. Its returning SFU_SUCCESS even though it fails to erase this 4kb memory out of 8kb slot. I hope Mr. Chris and Mr. Geoff has communicated with you regarding this.

I also had posted in ST community.

https://community.st.com/s/question/0D53W00000BsrdBSAR/sbsfu-abnormal-error-during-swapping-of-downloaded-firmware-image

I hope I recieve your help on this.

Thanks,

Ankush

[Piranha]

When your lower priority thread will work with the peripheral, higher priority thread can still preempt it and f*ck things up. Changing priority cannot solve a problem of access locking. Mutex (mutual exclusion) does that.