STM32MP157A-DK1 Evaluation (2) ST-Link Debug Function

cruelfox

STM32MP157A-DK1 Evaluation (2) ST-Link Debug Function [Copy link]

 

　　For boards like STM32MP157-DK running Linux, if you write the system to an SD card or Flash chip, and then wait for Linux to start and log in to operate, it is similar to playing Linux on a PC, except that there are many more hardware that can be directly accessed by the program. Compared with normal MCU development, the software writing freedom of STM32MP1 Linux is relatively large, at least there is enough RAM; access to hardware requires dealing with the operating system (Linux) rather than directly accessing registers.

　　But let's put these aside for now. The first time I got my hands on the ARM Cortex-A series processor, I planned to play with it as a single-chip microcomputer. According to the evaluation plan, it is necessary to implement "bare metal" programming of the STM32MP157, so there must be a way to put a program in it for the MPU to run. One way is to write the program to the startup code of the SD card, which is the first program read from the SD card after power-on (equivalent to writing the startup program in the MBR when playing with the PC); another way is to use a debugger, just like an MCU, to directly modify the contents of the memory and the values of the registers.

　　The STM32MP157A-DK comes with an ST-Link v2. The official introduction mainly mentions using its virtual serial port to connect to MP157 to implement Linux terminal, ROM boot and other functions that use UART. But obviously the main purpose of ST-Link is debugging, and the SWDIO and SWCLK signals of STM32MP157 have been connected to ST-Link. According to the chip manual, it can be determined that the Cortex-A7 core can also be debugged using SWD.
　　At first, I used the MCU download tool ST-Link_CLI to try the SWD connection, and the result was "No target connected" "Unable to connect to ST-LINK". I think it may be because the communication with the MPU is different from the previous STM32. The official introduction also did not mention the ST-Link Utility software dedicated to STM32MP1.

　　So how can I use this ST-Link? The clue I got from the Internet is to use OpenOCD:

　　First, openocd-stm32mp is mentioned on the wiki.st.com/stm32mpu/wiki/STM32MP15_OpenSTLinux_release_note page

Secondly, docs.zephyrproject.org/latest/boards/arm/96b_avenger96/doc/index.html mentions using openocd in the stm32mp1 developer package for debugging

Third, at sysprogs.com/VisualKernel/tutorials/stm32mp1/ , it explains how to debug Linux kernel modules, using the dedicated openocd tool

Here is a link to a Github page where you can download a compiled Windows version of openocd. However, due to network issues I could not always download it successfully.

　　Fourth, the answer on the ST community community.st.com/s/question/0D50X0000CAtzDH/can-i-debug-cortexa7-cores-on-stm32mp157 is about Can I debug Cortex-A7 cores on STM32MP157?

The ST staff confirmed that the A7 core can be debugged using the ST-Link on the board. The software is OpenOCD + GDB.

　　In the past, OpenOCD for debugging STM32 MCU did not support STM32MP157. You will know it after trying it. At least the configuration file is missing. So how to copy the configuration file? I searched for the dedicated OpenOCD (modified version, supporting STM32MP1) provided by ST on github.com/STMicroelectronics/device-stm-openocd, which can be git cloned to the local computer. There is a compiled Linux program with other script files. The source code directory does not have the original openocd code, mainly patches. I tried to copy the configuration file and try it with openocd under Windows. The result was an error. It seems that the script file is not compatible between different versions of openocd. As for the compiled openocd, I tried the Glibc version on my unit computer and it could not run. My own PC Linux is 32-bit, so I can't use it for testing.

　　The official SDK is also an x86_64 version, so the Linux on my PC cannot run it. I either have to compile a set of GLibc runtime libraries for x86_64 to support the programs in the official SDK, or compile OpenOCD and GDB, as well as the ARM GCC toolchain on the existing system. Both are troublesome. I decided to do the latter.

　　

　　The last official release of OpenOCD is 0.10.0, which is not difficult to compile. For special libraries, you only need libusb 1.x or 0.x, and libusb can be compiled with libudev, which is easy to do. I play with STM32 myself, because I always use Windows for development, and I don’t have much Linux tools, so I have to start from scratch.

　　After successfully compiling OpenOCD and confirming that it can be used to access st-link to debug an MCU, I planned to put the STM32MP1 patch in (from ST above). As a result, many patches failed. Later I realized that in addition to the officially released version, the version under development of OpenOCD has been changing (the commands are also changing and are not compatible with the old ones), so the current requirement cannot be changed with version 0.10.0.

　　So I downloaded a very new snapshot version from the OpenOCD mirror site, unzipped it and tried to patch it, but it still failed a lot. I guess this is unavoidable. I am not familiar with version management, so it is not realistic to analyze how to patch it. It is too much trouble, so I might as well try another way.

　　There is also a question and answer in the ST community:

I'm upstreaming the support for STM32MP1 in mainline OpenOCD.

Today there is a conflict between some other patches waiting to be merged and the ST code to handle ST-Link in the way required by STM32MP1. This conflict prevents merging STM32MP1 code.

I hope this will get solved soon." This means that there is a conflict between this ST patch and other (new patches are constantly being released). So the latest snapshot I downloaded cannot be used to change to the STM32MP1-specific version. So how do I know which original version ST is using?

　　Fortunately, I found it. It is hidden in the description of github.com/STMicroelectronics/meta-st-stm32mp/blob/thud/recipes-devtools/openocd/openocd-stm32mp_0.10.0.bb :

Follow this string to find the OpenOCD git mirror and you can download it. Then apply ST's patch, perfect!

　　However, this git version of openocd needs to be autoconfigured before the configure program can be obtained. First, the bootstrap script must be executed. Because the versions of autoconf, automake, and m4 software on my Linux are too old, I recompiled and upgraded them, which are just minor episodes. When compiling this new version of openocd, I encountered some minor problems, which I fixed manually.

　　After make install, connect to the development board and give it a try:

This means that OpenOCD has recognized two Cortex-A CPU cores. The first step was finally successful.

　　I have learned from reading ARM documents that there are big differences between Cortex-A7 and Cortex-M0/4. Now I can finally use the debugging tools, which will be of great help in observing the CPU status. You can also try the memory access and disassembly functions of OpenOCD.

　　For example, interrupt the CPU execution and check where the code is currently running:

[fox@ULFS]~$ telnet localhost 4444
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
Open On-Chip Debugger
> halt
stm32mp15x.cpu0 rev 5, partnum c07, arch f, variant 0, implementor 41
stm32mp15x.cpu0 cluster 0 core 0 multi core
stm32mp15x.cpu1 rev 5, partnum c07, arch f, variant 0, implementor 41
stm32mp15x.cpu1 cluster 0 core 1 multi core
target halted in ARM state due to debug-request, current mode: Supervisor
cpsr: 0x60030093 pc: 0xc011b368
MMU: enabled, D-Cache: enabled, I-Cache: enabled
target halted in ARM state due to debug-request, current mode: Supervisor
cpsr: 0x200b0193 pc: 0xc015db00
MMU: enabled, D-Cache: enabled, I-Cache: enabled
> reg pc
pc (/32): 0xC015DB00
> arm disassemble 0xC015DB00 20
0xc015db00 0xe58d3038 STR r3, [r13, #0x38]
0xc015db04 0x0a000031 BEQ 0xc015dbd0
0xc015db08 0xe1a0300d MOV r3, r13
0xc015db0c 0xe3c32d7f BIC r2, r3, #0x1fc0
0xc015db10 0xe3c2203f BIC r2, r2, #0x3f
0xc015db14 0xe3031d00 MOVW r1, #0x3d00
0xc015db18 0xe34c1100 MOVT r1, #0xc100
0xc015db1c 0xe592300c LDR r3, [r2, #0xc]
0xc015db20 0xe5910000 LDR r0, [r1]
0xc015db24 0xe593c020 LDR r12, [r3, #0x20]
0xc015db28 0xe2600064 RSB r0, r0, #0x64
0xc015db2c 0xe170000c CMN r0, r12
0xc015db30 0x4a000063 BMI 0xc015dcc4
0xc015db34 0xe5931024 LDR r1, [r3, #0x24]
0xc015db38 0xe15b0001 CMP r11, r1
0xc015db3c 0x0a000005 BEQ 0xc015db58
0xc015db40 0xe583b024 STR r11, [r3, #0x24]
0xc015db44 0xe592100c LDR r1, [r2, #0xc]
0xc015db48 0xe591301c LDR r3, [r1, #0x1c]
0xc015db4c 0xe2833001 ADD r3, r3, #0x1

This content is originally created by cruelfox , a user on the EEWORLD forum. If you want to reprint or use it for commercial purposes, you must obtain the author's consent and indicate the source

okhxyyo

Thank you for sharing