Flashing Code to STM32N657X0-Q using STM32CubeIDE or STM32CubeProgrammer

[Dila]

 

Hello,

We are working with the STM32N657X0-Q and we would like to understand the best way to flash my C/C++ program onto the board using STM32CubeIDE or STM32CubeProgrammer.

Specifically, we have the following questions:

1. Flashing from STM32CubeIDE:

   • Is it possible to directly flash my compiled C/C++ program to the STM32N657X0-Q using STM32CubeIDE?

   • If yes, what are the required configurations for the debugger and the flash settings?

2. Using a Binary or Hex File:

   • When compiling a project in STM32CubeIDE, where can I find the generated .bin or .hex file?

   • What are the correct steps to extract the binary or hex file from STM32CubeIDE? ==>  We managed to retrieve binary and hex files from STM32CubeIDE, but we are unable to flash them using STM32CubeProgrammer.
     

3. Flashing with STM32CubeProgrammer:

   • Once I have the .bin or .hex file, what is the correct procedure to flash it onto the STM32N657X0-Q using STM32CubeProgrammer?

   • Are there specific memory regions or settings that I need to configure before flashing?

We would really appreciate any guidance or step-by-step instructions on this process. Thank you in advance for your help!

Best regards,

Dila

[Yasir7]

Same problem I m facing . I can't find procedure

[callsignhermit]

By default, CubeIDE generates only the .elf file. If you want to create the raw binary in a post-build step, open project properties, navigate to C/C++ Build > Settings > Tool Settings > MCU/MPU Post Build Outputs, and select Convert to Binary File. The .bin file will be generated inside the configuration folder, next to the .elf and others (usually the Debug folder inside your project directory)

Flashing raw binaries in STM32CubeProgrammer is pretty straightforward. The Erasing & Programming pane is designed for this purpose. However, it is not really shipped with CubeIDE, but if you must, you can do one of these things:

Using a Custom Launch Configuration

1. Create a new configuration in the Run Configuration window.
2. Open the Startup pane in the configuration’s settings.
3. Inside the Load Images and Symbols list, select the file that is already there, then choose Edit.
4. In the Add/Edit Item window that opens, deselect both Download and Load Symbols. Then choose OK to get back to the Configurations window.
5. Click on the Add button to add your binary file.
6. Now in the Add/Edit Item window, you may point CubeIDE to your binary either with an absolute path via the File System… button, or you if the binary file is already inside your project directory, choose the project from the Project drop-down menu and use a relative path inside the Program Path textbox. Just remember, you can’t choose Debug in the Build Configuration drop-down menu, as it requires a .elf file. You may choose Release (you would have to put your binary file inside the Release folder) or choose the empty item and give the path to the binary file relative to the project path.
7. Still in the Add/Edit Item window, select the Download checkbox and enter the download address. The address is where the binary file’s contents will be placed in the MCU flash, and should be given to you by whoever generated the binary file. It is usually 0x8000000 for STM.
8. Save the Run Configuration and close the Run Configurations window.

You may now launch the configuration from the Run Configuration drop-down menu and it should download your binary into the file, albeit it also runs a GDB server on localhost which does nothing.

Using an External Tool Configuration

1. Create a new configuration in the External Tools Configuration window.
2. Open the Main pane in the configuration’s settings.
3. Enter ${cubeide_cubeprogrammer_path}/STM32_Programmer_CLI inside the Location textbox. You may specify the absolute path to STM32CubeProgrammer too, but I preferred to use the Eclipse variable.
4. Enter ${project_loc} in the Working Directory textbox.
5. Enter --connect port=SWD speed=fast mode=UR reset=hwRst --download /path/to/the/binary/file 0x08000000 --verify --log /tmp/STM32CubeProgrammer.log in the Arguments textbox. Replace /path/to/the/binary/file with wherever the file is. You may use an absolute path or a path relative to whatever you entered as the working directory; I prefer to keep it parametric, place the binary file inside the Release folder, rename it to the project’s name, then enter Release/${project_name}.bin. You can remove the --log flag. This is actually the command performed by the GDB server to initiate flashing, the only difference is that it specifies a .bin file instead of GDB’s .srec and also specifies the memory location as is necessary with .bin files.
6. Save the External Configuration and close the External Configuration window.

You may now launch the configuration by first clicking on your project in STM32CubeIDE’s file explorer (so that the Eclipse variables have something to work with) then selecting the external tool from the External Configuration drop-down menu. It should do the job without bothering GDB. Note that you have to manually restart the board once flashing is done, as the reset command is issued by the GDB server, which we forego in this method. You can also add an --rst to the arguments to tell the flashing tool to perform a reset once it finishes.

Additional Info on How CubeIDE Launches

CubeIDE’s launch configurations run STM’s proprietary version of GDB server with a -cp option pointing to the flashing tool chosen in Build Configuration > Debugger > Debugging Probe. These serve as the “backend” to the GDB server’s “frontend”, talking to your hardware probe based on the debugging commands you send to the GDB server—either via Eclipse GUI or directly via the Debugger Console, acting as the GDB client.

The flashing tools used by CubeIDE, among with the GDB server executable, are all inside the plugin folder. That would be /Applications/STM32CubeIDE.app/Contents/Eclipse/plugins/ in macOS. These plugins are what really turns Eclipse into CubeIDE. There’s OpenOCD, CubeProg, JLink—all the fun stuff. You may use them yourself in a shell, although installing your own versions via some package manager would be more natural. The Run/Debug Configurations also use these executables; in the IDE you can simply navigate to Run > Run Configurations… > Debugger, choose Show Command Line, and inspect what directory is fed to the GDB Server with the -cp option.

When you tap the Run/Debug inside CubeIDE, the IDE runs the build tool on your source files, generates some files—including a .elf—inside its designated folder in your project directory, then feeds the .elf to the GDB server, which in turn runs the flashing tool to program the MCU. Once the flashing tool is done, the GDB server loads symbols using the same .elf file, then sits nicely and quietly waiting for the GDB commands you send to its TCP port on localhost. 

The thing is, you can’t really feed GDB raw binaries, since, well, it’s a debugger; it needs all the additional data inside the .elf file to do its job. So you have two options: Either run the GDB server with a dummy .elf while telling it to download the .bin you provide, or you may completely forego CubeIDE’s launch configurations and create a new external tool configuration to directly run the flashing tool with the .bin file. Both these options may feel like turning the spoon around your head: The point of an IDE is to replace the ugly low level stuff with shiny GUI buttons; this is not the software you use when you have to deal with raw binaries.

You may inspect the GDB invocation by navigating to > Run Configurations > Debugger and clicking on Show Command Line. Checking the actual command that runs STM32CubeProgrammer however requires selecting the Log to File checkbox in the same window and specifying an output file. Launch once, then check the log file. For me it was something like this; I copy-pasted it into External Tool Configurations window with some minor modifications.

STM32_Programmer_CLI --connect port=SWD speed=fast mode=UR reset=hwRst --download /tmp/ST-LINK_GDB_server_4U6RAb.srec --verify --log /tmp/STM32CubeProgrammer_PVnDFH.log