Modify, rebuild and reload a firmware



1 Overview[edit]

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]

  • If minicom is already opened, please disconnect it to use the SW4STM32 built in serial console.
PC $> Ctrl + A then Q

3 Open SW4STM32 IDE[edit]

  • Open System Workbench for STM32 IDE
SW4STM32 workspace

4 Connect a console to the board[edit]

  • It's very convenient to use the serial console integrated in SW4STM32
SW4STM32 Open the serial device by clicking this item
  • Connection is ok if Linux log or prompt are displayed in the console windows.
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
Stop the target status widget
  • 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]

  • Open the import screen File > Import... and select Existing Project into Workspace
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
SW4STM32 workspace with project open

6 Build the firmware[edit]

  • Click the build button (the little hammer in the toolbar)
SW4STM32 build the project
  • Build is finished with no error
SW4STM32 build finished with no error

7 Upload and start the firmware[edit]

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

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

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]

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

9 Modify the firmware[edit]

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:

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]

10.1 Rebuild[edit]

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

10.2 Reload and start[edit]

Just relaunch the debug session but reply "No" to following popup in order to force load of the updated firmware.

Force Load of the updated firmware

10.3 Test[edit]

  • 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


Info.png 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

TeleTYpewriter

Microprocessor Unit

(Software)Integrated development/design/debugging environment

uniprocessor

Receive

Transmit

GNU dedugger, a portable debugger that runs on many Unix-like systems

Microcontroller Unit

Inter-Processor Communication Controller

Hardware Abstraction Layer

Universal Asynchronous Receiver/Transmitter

Attachments

Discussions