If, for personal reason, you prefer using another terminal (ssh, minicom), it's then recommended to stop the target status widget using the Serial port in SW4STM32 by right click on the bottom right corner then stop

Thanks to the STM32-CoPro-MPU which complete SW4STM32 from version 2.8.0, SW4STM32 can download a STM32MP1 Arm® Cortex®-M4 coprocessor firmware, load it and start a debug session in one click.

Selecting your project and right clicking for the first time on Debug As > ST's STM32 MPU C/C++ Application, a debug configuration is created in production mode thanks to the information found by the target widget status, right down on the picture hereafter: Addr: 10.48.0.79

This debug configuration is then automatically launched, resulting in a download of the STM32MP1 Arm® Cortex®-M4 coprocessor firmware, a load by the remoteproc framework and a start of GDB debug session in attach mode.

It is also possible to edit the debug configuration:

Select your OpenAMP_TTY_echo project

Right click on Debug As > Debug configurations... to open the Debug Configurations panel

The original firmware example receives a message for the host on one channel end sent back the same message to the host on the same channel. As this is not so obvious on which channel the message is received, we propose to modify the firmware in order to add an indication to know what is the channel that is receiving the message. Please modify main.c original code as follow:

When the firmware is running, you can output log from the firmware by using the following command:

cat /sys/kernel/debug/remoteproc/remoteproc0/trace0

After playing a while you can stop the firmware

Board $> echo stop > /sys/class/remoteproc/remoteproc0/state

And terminate the SW4STM32 debug session

<noinclude>
{{ArticleMainWriter | VincentA}}
[[Category:Sub-articles]]
__NOTOC__</noinclude>
==Overview==
This stage explains how to modify, rebuild and reload a STM32MP1 Arm® Cortex®-M4 coprocessor firmware.
It proposes to customize the STM32MP1 Cube Package application example OpenAMP_TTY_Echo using the MPU feature integrated in SW4STM32 IDE.
==Disconnect the minicom console==
* If minicom is already opened, please disconnect it to use the SW4STM32 built in serial console.
{{PC$}} Ctrl + A then Q
==Open SW4STM32 IDE==
* Open System Workbench for STM32 IDE
[[File: SW4STM32_workspace.png|thumb|upright=2|center|link=|SW4STM32 workspace]]
==Connect a console to the board ==
* It's very convenient to use the serial console integrated in SW4STM32
[[File: SW4STM32_workspace_serial_disconnect_1.png|thumb|upright=2|center|link=|SW4STM32 Open the serial device by clicking this item]]
* Connection is ok if Linux log or prompt are displayed in the console windows.
[[File: SW4STM32_workspace_serial_disconnect_2.png|thumb|upright=2|center|link=|SW4STM32 Serial Consol is ready ]]
* If, for personal reason, you prefer using another terminal (ssh, minicom), it's then recommended to stop the target status widget using the Serial port in SW4STM32 by right click on the bottom right corner then stop
[[File:Stop Serial widget zoom.png|thumb|upright=2|center|link=|Stop the target status widgetTarget Status Widget]]
* It will avoid the following repetitive pattern in your Linux console<pre>
root@stm32mp1:~# ifconfig; echo __END__:$?
eth0 Link encap:Ethernet HWaddr 00:80:E1:42:45:69
inet addr:10.48.1.143 Bcast:10.48.3.255 Mask:255.255.252.0
inet6 addr: fe80::280:e1ff:fe42:4569/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:37 errors:0 dropped:1 overruns:0 frame:0
TX packets:26 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:5776 (5.6 KiB) TX bytes:3146 (3.0 KiB)
Interrupt:63 Base address:0xc000
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:65536 Metric:1
RX packets:344 errors:0 dropped:0 overruns:0 frame:0
TX packets:344 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:22880 (22.3 KiB) TX bytes:22880 (22.3 KiB)
usb0 Link encap:Ethernet HWaddr 4A:06:6C:16:19:EC
inet addr:192.168.7.2 Bcast:192.168.7.255 Mask:255.255.255.0
inet6 addr: fe80::4806:6cff:fe16:19ec/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:396 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 B) TX bytes:115397 (112.6 KiB)
__END__:0</pre>
==Import an existing example in SW4STM32 IDE==
* Open the import screen '''File > Import...''' and select '''Existing Project into Workspace'''
[[File: SW4STM32_import.png|thumb|upright=2|center|link=|SW4STM32 import screen]]
* Browse and select '''OpenAMP_TTY_echo''' application example
:'''$HOME/STM32MPU_workspace/STM32MP15-Ecosystem-v1.0.0/Developer-Package/STM32Cube_FW_MP1_V1.0.0/Projects/{{{board_type}}}/Applications/OpenAMP/OpenAMP_TTY_echo'''
* Click '''finish'''
* The '''OpenAMP_TTY_echo''' project is open and you can browse inside using the left pan
[[File: SW4STM32_workspace_project_open.png|thumb|upright=2|center|link=|SW4STM32 workspace with project open]]
==Build the firmware==
* Click the build button (the little hammer in the toolbar)
[[File: SW4STM32_workspace_project_build.png|thumb|upright=2|center|link=|SW4STM32 build the project]]
* Build is finished with no error
[[File: SW4STM32_workspace_project_build_finished.png|thumb|upright=2|center|link=|SW4STM32 build finished with no error]]
==Upload and start the firmware==
Thanks to the STM32-CoPro-MPU which complete SW4STM32 from version 2.8.0, SW4STM32 can download a STM32MP1 Arm® Cortex®-M4 coprocessor firmware, load it and start a debug session in one click.
Selecting your project and right clicking for the first time on '''Debug As > ST's STM32 MPU C/C++ Application''', a debug configuration is created in production mode thanks to the information found by the '''target widget status''', right down on the picture hereafter: Addr: 10.48.0.79
[[File: SW4STM32_workspace_serial_disconnect_1.png|thumb|upright=2|center|link=|SW4STM32 Target Status Widget detecting connected target: Addr: 10.48.0.79]]
This debug configuration is then automatically launched, resulting in a download of the STM32MP1 Arm® Cortex®-M4 coprocessor firmware, a load by the remoteproc framework and a start of GDB debug session in attach mode.
It is also possible to edit the debug configuration:
*Select your OpenAMP_TTY_echo project
*Right click on '''Debug As > Debug configurations...''' to open the ''Debug Configurations'' panel
*If not already created, create your debug configuration by double clicking on '''"ST's STM32 MPU Debugging"'''
*Make sure the "Thru Linux core (production mode)" is selected
The inet Address of the board should be already filled. Else try to update it thanks to the button on the right
[[File:SW4STM32 Production Mode.png|thumb|upright=2|center|link=|Select Production mode in Startup pane of Debug Configuration]]
When configuration is ok, the "Debug" button,on the bottom right, turn to active and you can launch the debug session.
The debug in production mode' adds the cortex-M firmware transfer to the embedded Linux. This means also in case of network usage some specific pop-up appearing:
* the ''SSH Password'' is to complete: the default one is root.
[[File:DebugCfg-Launch-PM-EnterPwd.png|thumb|upright=2|center|link=|SSH password popup]]
* the ''RSA key'' is to be approved.
[[File:DebugCfg-Launch-PM-RSA.png|thumb|upright=2|center|link=|RSA key popup]]
After, download of the firmware SW4STM32 will start it and switch into ''Debug Perspective''. You can then use all features of the debugger.
For further information and support on new MPU feature in SW4STM32, refer to ''Help'' menu of SW4STM32 "Micro Processor Unit (MPU) Family - MCU support "
==Test the firmware==
The OpenAMP_TTY_echo firmware do the following:
*CPU2(CM4) initialize OPenAMP MW which initializes/configures IPCC peripheral through HAL and setup openamp-rpmsg framework infrastructure
*CPU2(CM4) creates 2 rpmsg channels for 2 virtual UART instances UART0 and UART1
*CPU2(CM4) is waiting for messages from CPU1(CA7) on these both channels
*When CPU2(CM4) receives a message on 1 Virtual UART instance/rpmsg channel, it sends the message back to CPU1(CA7) on the same Virtual UART instance
If you have used SW4STM32 to load and start the firmware you should reopen the serial console.
* Initialize the ttyRPMSG0 configuration
{{Board$}} stty -onlcr -echo -F /dev/ttyRPMSG0
* Read constantly the ttyRPMSG0 channel in background
{{Board$}} cat /dev/ttyRPMSG0 &
* Send a message on one ttyRPMSG0 channel and recieve the echo on the same ttyRPMSG0 channel
{{Board$}} echo "Hello Virtual UART0" > /dev/ttyRPMSG0
Hello Virtual UART0
* You can perform the same steps with the ttyRPMSG1 channel
* After playing a while you can stop the firmware
{{Board$}} echo stop > /sys/class/remoteproc/remoteproc0/state
* And terminate the SW4STM32 debug session
==Modify the firmware==
The original firmware example receives a message for the host on one channel end sent back the same message to the host on the same channel.<br>
As this is not so obvious on which channel the message is received, we propose to modify the firmware in order to add an indication to know what is the channel that is receiving the message.<br>
Please modify main.c original code as follow:
[[File: SW4STM32_workspace_project_modification.png|thumb|upright=2|center|link=|SW4STM32 main.c file modification]]
/* Infinite loop */
/* USER CODE BEGIN WHILE */
while (1)
{
OPENAMP_check_for_message();
/* USER CODE END WHILE */
if (VirtUart0RxMsg) {
{{highlight|char msg_to_transmit[MAX_BUFFER_SIZE];}}
{{highlight|int msg_size &#61; 0;}}
VirtUart0RxMsg = RESET;
{{highlight|msg_size &#61; snprintf(msg_to_transmit, MAX_BUFFER_SIZE, "Channel RPMSG0: ");}}
{{highlight|msg_size +&#61; snprintf(msg_to_transmit + msg_size, MAX_BUFFER_SIZE, "%s\n", VirtUart0ChannelBuffRx);}}
{{highlight|log_info("size of the message to transmit &#61; %d bytes\n", msg_size);}}
{{highlight|VIRT_UART_Transmit(&huart0, (uint8_t*)msg_to_transmit, msg_size);}}
}
if (VirtUart1RxMsg) {
{{highlight|char msg_to_transmit[MAX_BUFFER_SIZE];}}
{{highlight|uint16_t msg_size &#61; 0;}}
VirtUart1RxMsg = RESET;
{{highlight|msg_size &#61; snprintf(msg_to_transmit, MAX_BUFFER_SIZE, "Channel RPMSG1: ");}}
{{highlight|msg_size +&#61; snprintf(msg_to_transmit + msg_size, MAX_BUFFER_SIZE, "%s\n", VirtUart1ChannelBuffRx);}}
{{highlight|log_info("size of the message to transmit &#61; %d bytes\n", msg_size);}}
{{highlight|VIRT_UART_Transmit(&huart1, (uint8_t*)msg_to_transmit, msg_size);}}
}
/* USER CODE BEGIN 3 */
}
/* USER CODE END 3 */
* Save your modifications
==Rebuild, reload and test the modified firmware==
===Rebuild===
* Click the build button (the little hammer in the toolbar)
* Wait the end of the build
===Reload and start===
Just relaunch the debug session but reply "No" to following popup in order to force load of the updated firmware.
[[File:Force Load of the updated binary.png|thumb|upright=2|center|link=|Force Load of the updated firmware]]
===Test===
* Initialize the ttyRPMSG0 and ttyRPMSG1 configurations
{{Board$}} stty -onlcr -echo -F /dev/ttyRPMSG0
{{Board$}} stty -onlcr -echo -F /dev/ttyRPMSG1
* Read constantly the ttyRPMSG0 and ttyRPMSG1 channels in background
{{Board$}} cat /dev/ttyRPMSG0 &
{{Board$}} cat /dev/ttyRPMSG1 &
* Send a message on one ttyRPMSG0 channel and check the echo log
{{Board$}} echo "Hello Virtual UART0" > /dev/ttyRPMSG0
Channel RPMSG0: Hello Virtual UART0
* Send a message on one ttyRPMSG1 channel and check the echo log
{{Board$}} echo "Hello Virtual UART1" > /dev/ttyRPMSG1
Channel RPMSG1: Hello Virtual UART1<br>
{{Info| When the firmware is running, you can output log from the firmware by using the following command:<br><pre>cat /sys/kernel/debug/remoteproc/remoteproc0/trace0</pre> }}<br>
* After playing a while you can stop the firmware
{{Board$}} echo stop > /sys/class/remoteproc/remoteproc0/state
* And terminate the SW4STM32 debug session

Line 27:

Line 27:

* If, for personal reason, you prefer using another terminal (ssh, minicom), it's then recommended to stop the target status widget using the Serial port in SW4STM32 by right click on the bottom right corner then stop

* If, for personal reason, you prefer using another terminal (ssh, minicom), it's then recommended to stop the target status widget using the Serial port in SW4STM32 by right click on the bottom right corner then stop