Modify, rebuild and reload a firmware

This message will disappear after all relevant tasks have been resolved.

Semantic MediaWiki

There are 1 incomplete or pending task to finish installation of Semantic MediaWiki. An administrator or user with sufficient rights can complete it. This should be done before adding new data to avoid inconsistencies.

1. Overview[edit source]

This stage explains how to modify, rebuild and reload an STM32MP1 Arm® Cortex®-M4 coprocessor firmware.

It proposes to customize the STM32MP1 Cube Package application example "OpenAMP_TTY_Echo" using STM32CubeIDE.

2. Disconnect the "minicom" console[edit source]

If "minicom" is already opened, please disconnect it to use the STM32CubeIDE built-in serial console.

 Ctrl + A then Q

3. Open STM32CubeIDE[edit source]

Start STM32CubeIDE

STM32CubeIDE Starter Screen

Choose a workspace (default is fine)

Notice information provided in the "Information Center page" and close it. (you can open it later on)

Go into your workspace projet view

4. Import an existing example in STM32CubeIDE[edit source]

4.1. For STM32MP157x-DKx board[edit source]

Open the import screen File > Import... and select Existing Project into Workspace

STM32CubeIDE import screen

Browse and select OpenAMP_TTY_echo application example :

For ecosystem release v2.1.0 :

$HOME/STM32MPU_workspace/STM32MP15-Ecosystem-v2.1.0/Developer-Package/STM32Cube_FW_MP1_V1.3.0/Projects/STM32MP157C-DK2/Applications/OpenAMP/OpenAMP_TTY_echo/STM32CubeIDE

For ecosystem release v2.0.0 :

$HOME/STM32MPU_workspace/STM32MP15-Ecosystem-v2.0.0/Developer-Package/STM32Cube_FW_MP1_V1.2.0/Projects/STM32MP157C-DK2/Applications/OpenAMP/OpenAMP_TTY_echo/STM32CubeIDE

STM32CubeIDE brings a new project structure for dual core devices such as STM32MP1. A top level project contains sub-projects for each core.
Here OpenAMP_TTY_echo top project contains OpenAMP_TTY_echo_CM4 sub project. Keep the 2 projects selected and click on "Finish".

STM32CubeIDE project selection

The OpenAMP_TTY_echo project is opened and you can browse inside using the left pan.

OpenAMP_TTY_echo project structure

4.2. For STM32MP157x-EV1 board[edit source]

Open the import screen File > Import... and select Import ac6 System Workbench for STM32 Project

STM32CubeIDE import screen

Browse and select OpenAMP_TTY_echo application example :

For ecosystem release v2.1.0 : $HOME/STM32MPU_workspace/STM32MP15-Ecosystem-v2.1.0/Developer-Package/STM32Cube_FW_MP1_V1.3.0/Projects/STM32MP157C-EV1/Applications\OpenAMP\OpenAMP_TTY_echo\SW4STM32\OpenAMP_TTY_echo

For ecosystem release v2.0.0 :

$HOME/STM32MPU_workspace/STM32MP15-Ecosystem-v2.0.0/Developer-Package/STM32Cube_FW_MP1_V1.2.0/Projects/STM32MP157C-EV1/Applications\OpenAMP\OpenAMP_TTY_echo\SW4STM32\OpenAMP_TTY_echo

Select "Cortex M4" project when below window appears, else "OK" for all other questions :

STM32CubeIDE project selection

The OpenAMP_TTY_echo project is opened and you can browse inside using the left pan.

OpenAMP_TTY_echo project structure

5. Build the firmware[edit source]

Select project OpenAMP_TTY_Echo_CM4 and click the Build button (the little hammer in the toolbar)

"Build" is finished with no error

6. Check connection to the target[edit source]

STM32CubeIDE requires to be connected to Linux running on STM32MP1 device though serial connection.
This connection is automatically detected and configured when you have put cable on ST-Link port and board has booted.

You can check you can get Linux log and prompt by clicking on the "STM32 butterfly" button :

STM32CubeIDE Serial Console button

Connection is correct if Linux log or prompt are displayed in the console windows.

Your board might be connected to the PC by Ethernet, either using RJ45 (point to point or VLAN) or USB0 EthernetOverUSB gadget (point to point connection with PC using TypeA-TypeC cable). Screenshot below uses the second solution.

When serial connection is established, STM32CubeIDE automatically detects the board IP address and displays sit in the "Serial Target widget status" window in bottom right part of the screen.

STM32Cube Serial Target widget status

In case different status such as "busy" or "console in use", check you have no other terminal connected and close the console.

7. Start Debug Session[edit source]

Select your OpenAMP_TTY_echo_CM4 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 STM32 Cortex-M C/C++ Application and open "Debugger" pane.

Check IP address is correctly filled (1). Else, you can force detection using button on the right (2).
Make sure the "Thru Linux core (production mode)" is selected (3)
When configuration is correct, the "Debug" button (5) turns to active and you can launch the debug session. Else, error message appears in area (4).

STM32CubeIDE needs to use serial connection to the board to manage firmware download.
If the console is opened, it will request your approval to close it. Answer "yes".

SSH password popup

The debug in "production mode" adds the cortex-M firmware transfer to the embedded Linux. In case of network usage, some specific pop-up appears:

the SSH Password must be completed: the default one is "root".

SSH password popup

the RSA key must be approved.

RSA key popup

After, firmware download, STM32CubeIDE switches into Debug Perspective.

In "production mode", the firmware is not break at main. GDB is simply attached to the running target. You can then use all features of the debugger.

Information

To benefit of the best GDB debug experience it's recommended to upgrade the onboard ST-Link version with the latest release. You can simply do it from STM32CubeIDE using menu "Help -> ST-Link Upgrade"

For further information, refer to STM32CubeIDE documentation avaialble in my.st.com

8. Test the firmware[edit source]

The OpenAMP_TTY_echo_CM firmware do the following:

CPU2(CM4) initializes 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

Reopen the Serial console of STM32CubeIDE and enter following commands :

Initialize the ttyRPMSG0 configuration

 stty -onlcr -echo -F /dev/ttyRPMSG0

Read constantly the ttyRPMSG0 channel in background

 cat /dev/ttyRPMSG0 &

Send a message on one ttyRPMSG0 channel and receive the echo on the same ttyRPMSG0 channel

 echo "Hello Virtual UART0" > /dev/ttyRPMSG0
Hello Virtual UART0

You can perform the same steps with the ttyRPMSG1 channel

Terminate the STM32CubeIDE debug session will stop the firmware.

9. Modify the firmware[edit source]

The original firmware example receives a message for the host on one channel and acknolegde by returning 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 you to modify the firmware in order to add an indication to know what is the channel that is receiving the message.

For that, please modify main.c original code as follow:

  /* Infinite loop */
  /* USER CODE BEGIN WHILE */
  while (1)
  {

    OPENAMP_check_for_message();

    /* USER CODE END WHILE */
    if (VirtUart0RxMsg) {
      char msg_to_transmit[MAX_BUFFER_SIZE];
      int msg_size = 0;
      VirtUart0RxMsg = RESET;

      msg_size = snprintf(msg_to_transmit, MAX_BUFFER_SIZE, "Channel RPMSG0: ");
      msg_size += snprintf(msg_to_transmit + msg_size, MAX_BUFFER_SIZE, "%s\n", VirtUart0ChannelBuffRx);
      log_info("size of the message to transmit = %d bytes\n", msg_size);
      VIRT_UART_Transmit(&huart0, (uint8_t*)msg_to_transmit, msg_size);
    }

    if (VirtUart1RxMsg) {
      char msg_to_transmit[MAX_BUFFER_SIZE];
      uint16_t msg_size = 0;
      VirtUart1RxMsg = RESET;

      msg_size = snprintf(msg_to_transmit, MAX_BUFFER_SIZE, "Channel RPMSG1: ");
      msg_size += snprintf(msg_to_transmit + msg_size, MAX_BUFFER_SIZE, "%s\n", VirtUart1ChannelBuffRx);
      log_info("size of the message to transmit = %d bytes\n", msg_size);
      VIRT_UART_Transmit(&huart1, (uint8_t*)msg_to_transmit, msg_size);
    }
    /* USER CODE BEGIN 3 */
  }
  /* USER CODE END 3 */

Save your modifications.

10. Testing the modified firmware[edit source]

10.1. Relaunch debug session[edit source]

By clicking on the "Debug" button, STM32CubeIDE relaunches the debug session after performing an incremental build to take into account your modification .

If everything is correct, you will be back switch to "Debug Perspective" windows after reload of the new firmware.

10.2. Test[edit source]

Initialize the ttyRPMSG0 and ttyRPMSG1 configurations

 stty -onlcr -echo -F /dev/ttyRPMSG0
 stty -onlcr -echo -F /dev/ttyRPMSG1

Read constantly the ttyRPMSG0 and ttyRPMSG1 channels in background

 cat /dev/ttyRPMSG0 &
 cat /dev/ttyRPMSG1 &

Send a message on one ttyRPMSG0 channel and check the echo log

 echo "Hello Virtual UART0" > /dev/ttyRPMSG0
Channel RPMSG0: Hello Virtual UART0

Send a message on one ttyRPMSG1 channel and check the echo log

 echo "Hello Virtual UART1" > /dev/ttyRPMSG1
Channel RPMSG1: Hello Virtual UART1

Information

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

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

Terminate the STM32CubeIDE debug session.