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

meiss.M · ‎2020-07-09

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?

OlivierK · ‎2020-07-17

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

View solution in original post

Olivier GALLIEN · ‎2020-07-09

Hi @meiss.M

Just did some trials of loading M4 example code from CubeIDE1.3.1 with dunfell Starter Package and it works.

Could you share more precisely error you face ?

Thanks

Olivier

Olivier GALLIEN
In order to give better visibility on the answered topics, please click on 'Accept as Solution' on the reply which solved your issue or answered your question.

meiss.M · ‎2020-07-09

When looking in the /lib/firmware directory on the target, there is no uploaded elf file.

If I upload it by hand, load it into the co-processor, gdb seems to connect.

It is mainly because of the target upload.

On the thud distribution running on the target, the "Uploading to target process indication" flops up. This did not happen using my built using the dunfell distribution.

Is the CUBEIDE uploading via ssh scp?

Which yocto packages are necessary to cooperate with the CUBEIDE?

Olivier GALLIEN · ‎2020-07-09

Hi @meiss.M

Yes in "production mode" CubeIDE upload elf via ssh connection.

Not change here between thud and dunfell.

Which connection did you set between Host and target ? Ethernet Over USB ? Point to point or LAN ? Behind swith or proxy ?

Any error message from CubeIDE when starting debug ?

>> On the thud distribution running on the target, the "Uploading to target process indication" flops up

This is confusing me. What do you mean ?

Olivier

Olivier GALLIEN
In order to give better visibility on the answered topics, please click on 'Accept as Solution' on the reply which solved your issue or answered your question.

meiss.M · ‎2020-07-09

Messages on the CubeIDE is:

I am using ethernet via a different network, DHCP.

However for the thud build, I am using the same ethernet setup and it worked.

No source available for "g_pfnVectors() at 0x0"

It seems there were no shell commands executed on the target.

Olivier GALLIEN · ‎2020-07-09

Thanks @meiss.M

Could be interesting to get the OpenOCD console traces please

Olivier

Olivier GALLIEN
In order to give better visibility on the answered topics, please click on 'Accept as Solution' on the reply which solved your issue or answered your question.

meiss.M · ‎2020-07-09

>> On the thud distribution running on the target, the "Uploading to target process indication" flops up

This is confusing me. What do you mean ?

This is the process indicator when using the the thud build on the target.

On dunfell I do not get so far. - Same network configuration, CUBEIDE was not restarted after target upload failure on the dunfell built.

meiss.M · ‎2020-07-09

OPENOCD Trace on the dunfell build:

Open On-Chip Debugger 0.10.0+dev-01193-g5ce997d (2020-02-20-10:54)

Licensed under GNU GPL v2

For bug reports, read

http://openocd.org/doc/doxygen/bugs.html

cortex_a interrupt mask on

cortex_a domain access control fixup on

none separate

adapter speed: 8000 kHz

adapter_nsrst_assert_width: 200

adapter_nsrst_delay: 200

none srst_pulls_trst

srst_only srst_pulls_trst srst_gates_jtag srst_open_drain connect_deassert_srst

Info : Listening on port 6666 for tcl connections

Info : Listening on port 4444 for telnet connections

Info : STLINK V2J36S26 (API v2) VID:PID 0483:3752

Info : using stlink api v2

Info : Target voltage: 3.246134

Info : Unable to match requested speed 8000 kHz, using 4000 kHz

Info : clock speed 4000 kHz

Info : SRST line released

Info : stlink_connect(connect)

Info : SWD DPIDR 0x6ba02477

Info : STM32MP157CACx.cpu0: hardware has 6 breakpoints, 4 watchpoints

Info : STM32MP157CACx.cpu1: hardware has 6 breakpoints, 4 watchpoints

Error: Could not find MEM-AP to control the core

Info : Listening on port 3334 for gdb connections

Info : Listening on port 3333 for gdb connections

ap 0 selected, csw 0x10006000

Info : accepting 'gdb' connection on tcp/3333

Error: Target not examined yet

Info : New GDB Connection: 1, Target STM32MP157CACx.cpu2, state: unknown

undefined debug reason 7 - target needs reset

Error: Target not examined yet

Warn : target STM32MP157CACx.cpu2 is not halted (add breakpoint)

Error: can't add breakpoint: target running

Error: Target not examined yet

ap 0 selected, csw 0x10006000

shutdown command invoked

Info : dropped 'gdb' connection

meiss.M · ‎2020-07-09

Should I build my yocto with the previous openocd from thud?

Do you think this is an option?

Olivier GALLIEN · ‎2020-07-09

Hi @meiss.M

I understand you use a dunfell image built with Distribution package ?

Can you make a try with the delivered Starter Package ?

Are you under windows or Ubuntu ?

If Ubuntu can you please share content of /etc/udev/rules.d/49-stlinkv2-1.rules ?

Thx,

Olivier

Olivier GALLIEN
In order to give better visibility on the answered topics, please click on 'Accept as Solution' on the reply which solved your issue or answered your question.