M4 ELF build done in CUBEIDE is not uploaded to target on dunfell platform

[meiss.M]

The program can not be uploaded under the dunfell distribution via CUBEIDE 1.3.1 to the target system. Using the thud distribution, target uploads works.

Are there any hidden upload scripts in the CUBEIDE - how to debug the debug upload?

Which yocto packages are necessary to cooperate with the CUBEIDE?

[meiss.M]

I think the major issue is that the ELF file is not getting uploaded to the target device.

How can I check this in the CUBEIDE.

What is the CUBEIDE doing before uploading the ELF file to the target device?

[meiss.M]

BTW:

could you please add https openocd download support, since many users are companies are behind a firewall which only allows http git fetch:

diff --git a/recipes-devtools/openocd/openocd-stm32mp_0.10.0.bb b/recipes-devtools/openocd/openocd-stm32mp_0.10.0.bb
index 1f0e02f..76f08c3 100644
--- a/recipes-devtools/openocd/openocd-stm32mp_0.10.0.bb
+++ b/recipes-devtools/openocd/openocd-stm32mp_0.10.0.bb
@@ -5,7 +5,7 @@ LIC_FILES_CHKSUM = "file://COPYING;md5=b234ee4d69f5fce4486a80fdaf4a4263"
 
 require openocd-stm32mp.inc
 
-SRC_URI_prepend = " git://repo.or.cz/openocd.git;name=openocd "
+SRC_URI_prepend = " git://repo.or.cz/openocd.git;name=openocd;protocol=https "
 
 SRCREV_FORMAT = "openocd"
 SRCREV_openocd = "b5d2b1224fed3909aa3314339611ac5ac7ab0f82"

[meiss.M]

Even if the /lib/firmware path does not exist on the target device, there is no error produced, while uploading the ELF file using CUBEIDE.

[meiss.M]

I have replaced on my target dropbear_2019.78.bb with dropbear_2018.76.bb from thud.

Now the progress bar appears in the CUBEIDE.

I will now replace openocd from thud.

[meiss.M]

OK, I have also downgraded the openocd and I am using the thud build .bb package and now it works.

You may check the supported ssh protocols in eclipse with respect to the dropbear implementation before shipping.;)

@Community member​ were there any differences in the dunfell starter package compared to the git repository?

Many Greetings, Markus

[Olivier GALLIEN]

Hi @meiss.M​ 

Thanks for all these inputs and finding.

We will investigate this.

Olivier

[Olivier GALLIEN]

@meiss.M​ 

To complete information can you share linux version you use for host ?

Thx

Olivier

[meiss.M]

# lsb_release -d
 
Description: Ubuntu 18.04.4 LTS

within a docker environment.

On anther build system i use arch

However, the ssh related issues should be independent of the distro.

Please, add some ssh error checking in the CUBEIDE, maybe this can be done within the remote system explorer in eclipse?

[OlivierK]

Hi @meiss.M (Community Member)​ 

This issue has been understood. It is linked to the dropbear version that has changed in 5.4 dunfell version (OpenSTLinux 2.0) with a removed feature compared to the one in kernel 4.19 (OpenSTLinux V1.2)

An OpenSTLinux V2.0 patch will be released soon, for the time being as a workaround:

• From a Starter package:

copy "/usr/sbin/dropbear" binary file found on an OpenSTLinux V1.2 image to an OpenSTLinux V2.0 image.

• From a Distribution package:

Add at the end of conf/local.conf: PACKAGECONFIG_append_pn-dropbear = " "

Best Regards

Olivier

[OlivierK]

Hi,

​The fix is now published.

https://wiki.st.com/stm32mpu/wiki/STM32MP15_ecosystem_release_note_-_v2.0.0

https://wiki.st.com/stm32mpu/wiki/STM32MP15_OpenSTLinux_release_note_-_v2.0.0

some cipher methods have been disabled by the community for security reasons.

As a consequence some ssh requests from STM32CubeIDE may not be functional due to the dropbear package configuration.

In this case, you can either:

• refer to https://github.com/STMicroelectronics/meta-st-stm32mp/commit/36a9911705bd37df136e9ac51dbf418861d510c9
• or use the latest STM32MP1_Starter_Package_-_images :  https://wiki.st.com/stm32mpu/wiki/STM32MP1_Starter_Package_-_images

Best Regards,

Olivier