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.

Template:ArticleMainWriter

1. Overview[edit source]

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.

2. Disconnect the minicom console[edit source]

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

 Ctrl + A then Q

3. Open SW4STM32 IDE[edit source]

Open System Workbench for STM32 IDE

File:SW4STM32 workspace.png

SW4STM32 workspace

4. Connect a console to the board[edit source]

It's very convenient to use the serial console integrated in SW4STM32

File:SW4STM32 workspace serial disconnect 1.png

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

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

It will avoid the following repetitive pattern in your Linux console

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

5. Import an existing example in SW4STM32 IDE[edit source]

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

File:SW4STM32 import.png

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

SW4STM32 workspace with project open

6. Build the firmware[edit source]

Click the build button (the little hammer in the toolbar)

File:SW4STM32 workspace project build.png

SW4STM32 build the project

Build is finished with no error

File:SW4STM32 workspace project build finished.png

SW4STM32 build finished with no error

7. Upload and start the firmware[edit source]

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

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

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.

SSH password popup

the RSA key is to be approved.

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 "

8. Test the firmware[edit source]

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

 stty -onlcr -echo -F /dev/ttyRPMSG0

Read constantly the ttyRPMSG0 channel in background

 cat /dev/ttyRPMSG0 &

Send a message on one ttyRPMSG0 channel and recieve 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

After playing a while you can stop the firmware

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

And terminate the SW4STM32 debug session

9. Modify the firmware[edit source]

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:

File:SW4STM32 workspace project modification.png

SW4STM32 main.c file modification

  /* 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. Rebuild, reload and test the modified firmware[edit source]

10.1. Rebuild[edit source]

Click the build button (the little hammer in the toolbar)
Wait the end of the build

10.2. Reload and start[edit source]

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

Force Load of the updated firmware

10.3. 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

After playing a while you can stop the firmware

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

And terminate the SW4STM32 debug session