As is known, compatibility with the GNU toolkit and GDB support make virtually any popular development environment suitable for debugging a wide range of embedded platforms, most often free and legal. In theory.
What happens in practice when you try to make friends with STM32 and NetBeans, and is it possible in principle to get a workable system with the support of the latest stones - under the cut.
Some lyrics
I did not want to move out of the microchip. However, after the company's purchase of Atmela, they first covered up perhaps one of the most promising families in the company's portfolio - PIC32MM, and then the entire MIPS line. It became obvious that in the foreseeable future, the transition to ARM is inevitable, and since the Microchip for two years did not integrate the support of the atmelovsky controllers into its ecosystem, "Stay with us" did not give any advantages. Rather, the opposite is true: upward-adjusted pricing policies and the traditional organizational difficulties of merging companies have made Atmelovo AWPs less attractive. At the same time, the project turned up, on which the PIC32MZ just stumbled. The critical mass was gained.
Why STM: wide market coverage, budget debugging, free full-featured SW-4STM32 environment based on the open source, and the political aspect - ST Microelectronics is supported by the French government as a strategic resource, so there is no threat of a sudden exit from the market or takeover.
Debugging - First Impressions
SW4STM32 was established in the traditional way - by pressing the Next> button several times (* hereinafter, all experiments occur on Win7 x64). A demo project suitable for testing the necessary function was removed from the STM32Cube Firmware package, everything worked out more or less right out of the box. The first launch of the JTAG emulator left an impression: the entire cycle of entering debug mode, starting from the connection and ending with stopping at the beginning of main () with updating the context, it turns out, can take 1-2 seconds. Compared to microchip debuggers (even REAL ICE for half a thousand), the difference in speed is multiple!
And yet, something unpleasantly surprised.
What is wrong with Eclipse / SW4STM32
A myriad of settings and illogical organization, hidden menu items, perspectives, interface bugs and visual artifacts, missing frequently used hot buttons and functions on the toolbar, small clumsy unreadable icons and markers, the lack of “Find Usages” are partly subjective, and you can adapt if you wish . But: regularly forgets to save the modified files before the assembly, although all the checkboxes where necessary must be affixed; when forced manual saving does not see changes, and the incremental assembly is irrelevant; there is no complete rebuild (Clean and Build) as a single command, while after a forced cleanup through the Clean Project, the build fails (file access?), and successfully completed only on the 4th attempt - this is no longer a reasonable explanation. Even the early MPLAB X Beta releases based on the ancient NetBeans 6.xx did not have the same problems 10 years ago as the officially supported development environment for STM32 today.
In addition, with SW4STM32, 3 copies of typical IDEs are already typed in the system, since besides it there are still tightly nailed to NetBeans 8.0.1 and in some way fenced off MPLAB X (i.e. it is impossible to use it for other languages / platforms) and NetBeans 8.2 for Java and C / C ++.
It turns out that setting up NetBeans 8.2 for working with STM32 will eliminate the described practical problems of Eclipse, reduce the number of copies of the IDE, and reduce to one platform, albeit slightly different versions.
NetBeans 8.2 and GNU ARM Tools
NetBeans is better to use 32-bit, because in addition to double the memory consumption, it was not possible to detect the differences of the 64-bit version.
Google quickly found a
setup guide . The principal difference was only in the OS (they have Linux against Win7 x64), so the installation of the * MSX nix environment, which is included in the MinGW package, became a bonus game. The toolchain settings should be similar to:
The important point is that when adding the GNU ARM toolchain, select the “GNU MinGW” family, in which case NetBeans will correctly call MSYS. If Cygwin is already installed on the machine, it will be logical to use it, respectively, the GNU ARM family must select "GNU Cygwin".
Successful compilation was not easy, but very simple. Since SW4STM32 uses the same compiler, having looked at the command line of the compiler call in SW4STM32 and copied the missing keys in Project Properties → C Compiler → Additional Options
we get exactly the same output, but with an important practical difference - everything is collected from the first, Clean and Build is and works great:
But this result can be improved by adding optional Post-Build processing. Open the Makefile, and in the .build-post: .build-impl section add:
.build-post: .build-impl cp ${CND_DISTDIR}/${CONF}/${CND_ARTIFACT_NAME_${CONF}} ${CND_ARTIFACT_NAME_${CONF}} arm-none-eabi-objcopy -O ihex ${CND_ARTIFACT_NAME_${CONF}} ${CND_ARTIFACT_NAME_${CONF}}.hex arm-none-eabi-size ${CND_ARTIFACT_NAME_${CONF}}
(important - the indent must be a single tab character, not spaces)
Line by line: 1 - copies the object file (.elf) from the output folder to the project root, for easier access; 2 - generates HEX from elf (can be commented out if HEX is not needed); 3 - displays the amount of memory used by segments.
Final result:
So far, so good.
OpenOCD - the first difficulties
In the online guides mentioned, crystal programming through OpenOCD is simple and routine. The latest version (0.10.0) is installed, the configuration file is taken (from the OpenOCD bundle or from the SW4STM32 project folder), a command of the following type is entered into the Project Properties → Run:
and everything works right away. Indeed, this is the case for younger families of the type STM32F103 and F407, but I am interested in F7 and H7. With the first official version of OpenOCD 0.10.0 crashes with the errors "auto_probe failed" and "undefined debug reason 7"; the latter are not supported at all. Tried all available official builds 0.10.0 from January 2017 and January 2018 - the result is identical. A keyword search confirms the existence of the problem, although you cannot call it mass; parsing and no solution.
But there is a version that is guaranteed to work - from the set of SW4STM32. Naturally, it turns out to be improved and enhanced, with new scripts and support for the H7 family. Also, the file structure was changed in it, and the resources in the plugin are stored in a separate module, therefore, in order for the utility consolidated in a single folder to see its scripts, the –s key was required.
Board.cfg for the NUCLEO-F767ZI, minus the comments, and compressed:
set CHIPNAME STM32F767ZITx source [find interface/stlink-v2-1.cfg] transport select hla_swd source [find target/stm32f7x.cfg] set WORKAREASIZE 0x10000 set ENABLE_LOW_POWER 1 set STOP_WATCHDOG 1 reset_config srst_only srst_nogate connect_assert_srst set CONNECT_UNDER_RESET 1
Finally run through the Run Main Project:
The firmware is successful, the code is being executed.
Debugging
The scheme is the most traditional: a local GDB server on OpenOCD, NetBeans connects to it via localhost: 3333 via TCP. Accordingly, NetBeans will require the Gdbserver plugin.
You can simplify the launch of OpenOCD through a bat-script, and since after the session is over it goes to the console, it makes sense to loop restart endlessly:
:start openocd -f debug.cfg -sd:/Prog/openocd/scripts goto start
Run:
The version from SW4STM32 is not explicitly written, but the server is waiting for a TCP connection to port 3333. In NetBeans, you must select Debug → Attach Debugger ..., and install:
Session is active. OpenOCD terminal:
It looks good, the debug session is active, the code is being executed. However, the problem still exists.
Problem
In free run mode, execution cannot be stopped.
If you set a breakpoint before starting the session, when entering debugging, the context will be stopped with updating, step-by-step execution and viewing / changing of variables will work, i.e., in principle, all the basic functions necessary for full debugging:
But only until the next free launch, after which it remains only to close and restart the session.
Another unpleasant trifle is related to software breakpoints: the SYSTEM_Halt () function is defined as __asm__ (“bkpt”), and its triggering results in displaying an unnecessary dialog:
Pressing Discard and Pause works as required (i.e., stops execution), however it is not possible to set this option by default and disable the window display by standard means.
Hell, I would like to automate the launch of OpenOCD and the connection of the debugger directly through NetBeans.
However, objectively, the only function that is not enough for more or less complete debugging is to stop the execution (it is also required to set breakpoint on the fly).
Debug debugging
A Google search revealed that there were similar problems with a broken GDB stop in NetBeans, but were fixed a few years ago. In the absence of a better idea, the NetBeans sources were downloaded in the hope of running the debugger live. Surprisingly, it was rather quickly able to localize the problem before calling the external utility GdbKillProc.exe, which is essentially a wrapper for DebugBreakProcess (pid) from WinAPI. The principle of operation of the utility is reduced to non-intrusive interruption of the process (similar to “kill -SIGINT [pid]” under * nix, or Ctrl + C in the console).
But it does not work.
What is tested
In console mode, the GDB client (arm-none-eabi-gdb.exe) responds correctly to Ctrl + C, that is, it stops the execution of the code without closing the session, and waits for further instructions.
ps -W and Windows Process Explorer display the process correctly, and the PID matches the internal variable in NetBeans.
A manual call to "kill -SIGINT [pid]" from the MSYS package generates the error "No such process".
Checking through “taskkill / pid [pid]” gives out “The process ... couldn’t be terminated ... This process can only be terminated forcefully ...”, which seems to indicate a system lock. With the / f key, the process closes completely, which is also not suitable.
Along the way, it turned out that in Windows the situation with the generation of interrupt signals is unimportant, or rather, in no way: only the analogue SIGTERM is standardly supported, which corresponds to a rough cutting down of the process, and there is no generally accepted solution.
On the Internet, a windows-kill utility has been discovered, created to emulate Ctrl + C and Ctrl + Brk. The process finds, the interrupt sends without errors, but the GDB client still does not respond.
The experiments were carried out using all 32-bit versions (NetBeans, ARM Tools, MSYS 1.0), except for windows-kill, which 32-bit refused to start ("... unable to start correctly ..."). Perhaps this is the problem, because, according to the fragmentary data from forums and bug trackers, the bitness of the utility and the process should be the same. The difficulty here is that ARM does not offer the x64 version of the toolchain under Windows, that is, the only way to eliminate the heterogeneity is to make the x32 version of windows-kill work, which is also not clear if Win x64 is possible in principle.
In the middle of the process, the OS was reinstalled from scratch, and no changes in the experimental behavior were observed, that is, with great certainty, the features of a particular system can be eliminated.
Hall assistance required
Actually, all of the above can be considered an introduction to this paragraph.
The last step is to debug the STM32 under NetBeans real:
A running SIGINT interrupt signal transmission mechanism (Ctrl + C) is required in the GDB client process under WindowsBelow is a recommendation for setting a minimum configuration sufficient for checking / debugging the above problem. If / when it can be resolved, the article will be converted to a simple step-by-step guide on how to configure NetBeans + OpenOCD for several different families and debugging boards. Further functionality can be finished at will, already having a workable basic solution.
Test setup
As a hardware platform, it is proposed to use Blue Pill based on STM32F103C8T6 and clone ST-Link V2.
It is necessary:
1. Install
GNU Arm Embedded Toolchain2. Install OpenOCD 0.10.0 (
build under Win )
3. Register the bin folders of both packages in PATH (Control Panel → System → Advanced System Settings → Environment Variables ... → Path).
4. In a convenient place to create a file board.cfg, copy the contents:
source [find interface/stlink-v2.cfg] source [find target/stm32f1x.cfg] transport select "hla_swd" reset_config none separate set WORKAREASIZE 0x5000 set CHIPNAME STM32F103C8T6 set ENABLE_LOW_POWER 1 set STOP_WATCHDOG 1 set CLOCK_FREQ 4000 set CONNECT_UNDER_RESET 1
5. Choose a suitable test firmware (test.elf), the main criterion - so that the execution and the stop are clearly distinguishable. Copy to a convenient place.
6. From the convenient place to flash the board:
openocd -f board.cfg -c "program test.elf verify reset exit"The firmware should start. Approximate output of OpenOCD to the console:
7. From a convenient place to run the OpenOCD GDB server:
openocd -f board.cfgThe code is still running; approximate output (console remains locked by OpenOCD):
8. In another console or directly run arm-none-eabi-gdb.exe from the GNU ARM Embedded Toolchain package and execute the commands:
target extended-remote localhost:3333 (code still running)
continue (code is executed, the console is locked)
Ctrl+C (code stopped, console active)
continue (executed again, the console is locked)
The task is to bring the GDB client out of the running state (that is, in essence, to emulate Ctrl + C) programmatically.
To find out Process ID, use "ps -W" from * nix-environment, or Windows Process Explorer (optional).
It is possible that debugging will work correctly for someone right after the initial configuration of NetBeans - such information will also be useful, especially with a detailed description of the system and possible features.
Please share ideas in the comments, and I hope that by joint efforts we will be able to turn a bold experiment into a useful guide to setting up an even more useful tool.