2020-12-04 01:56 AM
I have a custom built buildroot image on my STM32MP157C-DK2. Used STM32CubeIDE 1.5.0 to create a M4 blinky project. Can download and run the .elf manually on the board, LED blinks okay. Engineering Mode works too. In Production Mode, I can download the .elf from IDE. Have to enter my credentials and see the download progress and the resulting .elf on the board.
But, after download, I have to enter the same credentials again and .. finally get:
Error in final launch sequence:
Failed to execute MI command:
target remote 192.168.2.44:3333
Error message from debugger back end:
192.168.2.44:3333: Connection timed out.
Failed to execute MI command:
target remote 192.168.2.44:3333
Error message from debugger back end:
192.168.2.44:3333: Connection timed out.
192.168.2.44:3333: Connection timed out.
There serial connection says:
[ 2174.385112] remoteproc remoteproc0: stopped remote processor m4
[ 2179.484162] remoteproc remoteproc0: powering up m4
[ 2179.493251] remoteproc remoteproc0: Booting fw image Hello_stm32mp157c_dk2_CM4.elf, size 2489804
[ 2179.500701] remoteproc remoteproc0: header-less resource table
[ 2179.506452] remoteproc remoteproc0: no resource table found for this firmware
[ 2179.513765] remoteproc remoteproc0: header-less resource table
[ 2179.519465] remoteproc remoteproc0: remote processor m4 is now up
-ne
-sh: -ne: not found
Don't get, what's missing. There is a local gdbserver in the image. Is there an option to increase verbosity, i.e. to find out what the credentials are needed for 2nd time etc..?
Thanks
KnarfB
Solved! Go to Solution.
2020-12-07 02:10 AM
Hi @KnarfB ,
Sorry for the misunderstanding, I was confused by the "custom build" sentence.
Anyway we have an issue with remoteProc framework, you should get something like :
[1033742.136156] remoteproc remoteproc0: stopped remote processor m4
[1033744.183138] remoteproc remoteproc0: powering up m4
[1033744.193205] remoteproc remoteproc0: Booting fw image dk2-mx_CM4.elf, size 2660280
[1033744.199826] remoteproc0#vdev0buffer: assigned reserved memory node vdev0buffer@10042000
[1033744.208425] virtio_rpmsg_bus virtio0: rpmsg host is online
[1033744.213738] remoteproc0#vdev0buffer: registered virtio0 (type 7)
[1033744.219753] remoteproc remoteproc0: remote processor m4 is now up
Could you double-check the version of your Linux booted on the target:
root@stm32mp1:/usr/local/projects/dk2-mx_CM4# uname -a
Linux stm32mp1 5.4.56 #1 SMP PREEMPT Wed Aug 5 07:59:52 UTC 2020 armv7l armv7l armv7l GNU/Linux
You can try to load manually your elf via the Linux console:
root@stm32mp1:/# cd /usr/local/projects/Hello_stm32mp157c_dk2_CM4/
root@stm32mp1:/usr/local/projects/Hello_stm32mp157c_dk2_CM4# ./fw_cortex_m4.sh stop
root@stm32mp1:/usr/local/projects/Hello_stm32mp157c_dk2_CM4# ./fw_cortex_m4.sh start
Ludovic
2020-12-04 06:28 AM
Hello @KnarfB ,
I think your are missing the resource_table section needed by remoteProc Linux framework:
.resource_table :
{
. = ALIGN(4);
KEEP (*(.resource_table*))
. = ALIGN(4);
} >RAM1_data
Could you compare your .ld file with one generated by STM32CubeIDE ?
Hope this help,
Ludovic
2020-12-04 07:53 AM
Hi Ludovic,
thanks for your reply. No, I didn't change .ld and that section is present in .elf (but has size 0).
Used STM32CubeIDE 1.5.0 to create a new STM32MP157C-DK2 project with "all peripherals". Just assigned LED_Y GPIO to M4.
Same behavior also with OpenAMP_TTY_echo_CM4 stock example: can download it from IDE (scp?) but debugger connection times out.
KnarfB
2020-12-07 02:10 AM
Hi @KnarfB ,
Sorry for the misunderstanding, I was confused by the "custom build" sentence.
Anyway we have an issue with remoteProc framework, you should get something like :
[1033742.136156] remoteproc remoteproc0: stopped remote processor m4
[1033744.183138] remoteproc remoteproc0: powering up m4
[1033744.193205] remoteproc remoteproc0: Booting fw image dk2-mx_CM4.elf, size 2660280
[1033744.199826] remoteproc0#vdev0buffer: assigned reserved memory node vdev0buffer@10042000
[1033744.208425] virtio_rpmsg_bus virtio0: rpmsg host is online
[1033744.213738] remoteproc0#vdev0buffer: registered virtio0 (type 7)
[1033744.219753] remoteproc remoteproc0: remote processor m4 is now up
Could you double-check the version of your Linux booted on the target:
root@stm32mp1:/usr/local/projects/dk2-mx_CM4# uname -a
Linux stm32mp1 5.4.56 #1 SMP PREEMPT Wed Aug 5 07:59:52 UTC 2020 armv7l armv7l armv7l GNU/Linux
You can try to load manually your elf via the Linux console:
root@stm32mp1:/# cd /usr/local/projects/Hello_stm32mp157c_dk2_CM4/
root@stm32mp1:/usr/local/projects/Hello_stm32mp157c_dk2_CM4# ./fw_cortex_m4.sh stop
root@stm32mp1:/usr/local/projects/Hello_stm32mp157c_dk2_CM4# ./fw_cortex_m4.sh start
Ludovic
2020-12-10 12:43 AM
Hi @LudovicR ,
thanks for your answer. I could solve my issues by taking a close look at the OpenAMP_TTY_echo_CM4 example
KnarfB