cnoviello / cubemximporter

This tool can be used to import projects generated by STM32CubeMX tool inside an Eclipse project created with the GNU ARM Eclipse plugin

CubeMXImporter

This tool can be used to import projects generated by STM32CubeMX tool inside an Eclipse project created with the GNU ARM Eclipse plugin. This release supports also the import of Middleware libraries (FatFS, LwIP, FreeRTOS, etc).

It can be easily used in this way:

1. Generate a new Eclipse project using the GNU ARM Eclipse plugin as described in this blog post or in this book.
   1. Close the prject once generated
2. Create a new CubeMX project for your MCU or development board. 2. Generate the C code from CubeMX project selecting SW4STM32 as Tool-chain.
3. Launch the CubeMXImporter tool with the following command:

$ python cubemximporter.py <path-to-eclipse-project> <path-to-cubemx-project>

4. Open again the Eclipse project and do a refresh of the source tree.

The whole procedure is better described here

CubeMXImporter works both with Python 2.7 and 3.x. It requires the lxml library. Linux and MacOS X users can install it using pip:

$ pip install lxml

while Windows users can download this pre-compiled package.

cubemximporter's Issues

No longer works with CubeMX 4.14

Apparently, CubeMX introduces a new way to generate the SW4STM32 project that breaks CubeMXImporter

CubeMXImporter unable to find startup_x.s file

Hi,

I got a problem when using this tool, i'm using CubeMX version 4.25.0.

\CubeMXImporter>python cubemximporter.py ..\projects\hello_cube2 ..\cubemx_out\nucleo64_f103rb
Traceback (most recent call last):
File "cubemximporter.py", line 544, in
cubeImporter.importCMSIS()
File "cubemximporter.py", line 318, in importCMSIS
shutil.copy(loc[0], loc[1])
File "C:\Python27\lib\shutil.py", line 133, in copy
copyfile(src, dst)
File "C:\Python27\lib\shutil.py", line 96, in copyfile
with open(src, 'rb') as fsrc:
IOError: [Errno 2] No such file or directory: '..\cubemx_out\nucleo64_f103rb\startup/startup_stm32f103xb.s'

CubeMX 4.25.0 places the startup file on the SW4STM32 directory:

(my cube project directory)\SW4STM32> dir
20/03/2018 05:00 p. m. 11,536 startup_stm32f103xb.s

So i think the script is searching the startup file on a wrong directory.
Can you reproduce the problem or i'm doing something wrong?

Regards,
Carlos

STM32L4_Evaluation debug blocked

I will work with mcu stm32l4, so I want to use this srcipt to generate project. I successfully completed this scrpit with stm32f103 nuleo after reflash JLink, but with mcu smt32l4, I got this console message:

SEGGER J-Link GDB Server V6.20h Command Line Version
JLinkARM.dll V6.20h (DLL compiled Oct 27 2017 16:21:36)
Command line: -if swd -device STM32L476ZG -endian little -speed 1000 -port 2331 -swoport 2332 -telnetport 2333 -vd -ir -localhostonly 1 -singlerun -strict -timeout 0 -nogui
-----GDB Server start settings-----
GDBInit file:                  none
GDB Server Listening port:     2331
SWO raw output listening port: 2332
Terminal I/O port:             2333
Accept remote connection:      localhost only
Generate logfile:              off
Verify download:               on
Init regs on start:            on
Silent mode:                   off
Single run mode:               on
Target connection timeout:     0 ms
------J-Link related settings------
J-Link Host interface:         USB
J-Link script:                 none
J-Link settings file:          none
------Target related settings------
Target device:                 STM32L476ZG
Target interface:              SWD
Target interface speed:        1000kHz
Target endian:                 little

Connecting to J-Link...
J-Link is connected.
Firmware: J-Link STLink V21 compiled Jun 26 2017 10:35:16
Hardware: V1.00
S/N: 778115647
Checking target voltage...
Target voltage: 3.30 V
Listening on TCP/IP port 2331
Connecting to target...Connected to target
Waiting for GDB connection...Connected to 127.0.0.1
Reading all registers
Read 4 bytes @ address 0x00000000 (Data = 0x20020000)
Read 2 bytes @ address 0x00000000 (Data = 0x0000)
Received monitor command: speed 1000
Target interface speed set to 1000 kHz
Received monitor command: clrbp
Received monitor command: reset
Resetting target
Received monitor command: halt
Halting target CPU...
...Target halted (PC = 0x0800029C)
Received monitor command: regs
R0 = 00000000, R1 = 00000000, R2 = 00000000, R3 = 00000000
R4 = 00000000, R5 = 00000000, R6 = 00000000, R7 = 00000000
R8 = 00000000, R9 = 00000000, R10= 00000000, R11= 00000000
R12= 00000000, R13= 20020000, MSP= 20020000, PSP= 00000000
R14(LR) = FFFFFFFF, R15(PC) = 0800029C
XPSR 01000000, APSR 00000000, EPSR 01000000, IPSR 00000000
CFBP 00000000, CONTROL 00, FAULTMASK 00, BASEPRI 00, PRIMASK 00
Reading all registers
Read 4 bytes @ address 0x0800029C (Data = 0xF7FFB508)
Read 2 bytes @ address 0x0800029C (Data = 0xB508)
Received monitor command: speed auto
Select auto target interface speed (2000 kHz)
Received monitor command: flash breakpoints 1
Flash breakpoints enabled
Received monitor command: semihosting enable
Semi-hosting enabled (Handle on BKPT)
Received monitor command: semihosting IOClient 1
Semihosting I/O set to TELNET Client
Received monitor command: SWO DisableTarget 0xFFFFFFFF
SWO disabled successfully.
Received monitor command: SWO EnableTarget 4000000 1000000 0x1 0
SWO enabled successfully.
Read 4 bytes @ address 0x0800029C (Data = 0xF7FFB508)
Downloading 928 bytes @ address 0x08000000 - Verified OK
Downloading 40 bytes @ address 0x080003A0 - Verified OK
Downloading 7259 bytes @ address 0x080003D0 - Verified OK
Downloading 120 bytes @ address 0x0800202C - Verified OK
Comparing flash   [....................] Done.
Verifying flash   [....................] Done.
Writing register (PC = 0x08000188)
Read 4 bytes @ address 0x08000188 (Data = 0xB083B500)
Received monitor command: clrbp
Received monitor command: reset
Resetting target
Received monitor command: halt
Halting target CPU...
...Target halted (PC = 0x0800029C)
Received monitor command: regs
R0 = 00000000, R1 = 00000000, R2 = 00000000, R3 = 00000000
R4 = 00000000, R5 = 00000000, R6 = 00000000, R7 = 00000000
R8 = 00000000, R9 = 00000000, R10= 00000000, R11= 00000000
R12= 00000000, R13= 20020000, MSP= 20020000, PSP= 00000000
R14(LR) = FFFFFFFF, R15(PC) = 0800029C
XPSR 01000000, APSR 00000000, EPSR 01000000, IPSR 00000000
CFBP 00000000, CONTROL 00, FAULTMASK 00, BASEPRI 00, PRIMASK 00
Reading all registers
Read 4 bytes @ address 0x0800029C (Data = 0xF7FFB508)
Starting target CPU...

Do you have any idea about my configuration of debug?
Thanks

Adding the ability to automatically arrange the mem.ld file with right FLASH address

It can be useful to add the ability to automatically arrange the mem.ld file with right FLASH address.

File structure changed?

Can it handle the changes in the file structure of the CUBEMX, there are differences in the file paths provided in the book and the generated locations

cubemximporter.py: error: unrecognized arguments

I'm trying to use the importer using the command bellow; but I'm getting an error message...Any help?
I'm using Cygwin terminal under Windows

$ python cubemximporter.py C:\Users\dell pc\Desktop\STM_Pojects\Test_Nucleo_F7 C:\Users\dell pc\Desktop\STM_Pojects\Cube\Cube_Nucleo_Basic

usage: cubemximporter.py [-h] [-v VERBOSE] [--dryrun]
eclipse_project_folder cubemx_project_folder
cubemximporter.py: error: unrecognized arguments: C:UsersdellpcDesktopSTM_PojectsCubeCube_Nucleo_Basic

wrong regexp for HAL_MCU_TYPE

self.HAL_TYPE = re.split("([F,L]{1}[0-9]{1})", self.HAL_MCU_TYPE)[1]
the , in [F,L] is plain wrong, check with STM32,103RBTx
the {1} is redundant and there is no need for the split as well.

Try with something like re.search("([FL][0-9])", self.MCU).group(1))

ERROR: make: *** No rule to make target 'system/src/cmsis/vectors_stm32f0xx.o', needed by 'helloCubeMX.elf'.

I'm working through Mastering STM32 and a compile error occurred when using CubeMXImporter with a Nucleo-STM32F091. It looks like the make file has an error, however I also noticed that 'system/src/cmsis/vectors_stm32f0xx.c' does not exist within the project.

Error: "multiple definition of `_sbrk'" in src/syscalls.c

I am using STM32F4 Discovery board following the step by step in 'Mastering STM32' - Carmine Noviello (Aug-2018). I have tried to import the CubeMX code generated project to the existed project in eclipse and it has got this error.
Eclipse: Oxygen.3a Release (4.7.3a)
Cube MX: 5.6.1
ARM GCC: gcc-arm-none-eabi-9-2019-q4-major-win32

c:/smt32toolchain/gcc-arm/bin/../lib/gcc/arm-none-eabi/9.2.1/../../../../arm-none-eabi/bin/ld.exe: ./src/syscalls.o: in function _sbrk':
C:\SMT32Toolchain\projects\Blinky\Debug/../src/syscalls.c:118: multiple definition of _sbrk'; ./system/src/newlib/_sbrk.o:C:\SMT32Toolchain\projects\Blinky\Debug/../system/src/newlib/_sbrk.c:45: first defined here collect2.exe: error: ld returned 1 exit status make: *** [makefile:64: Blinky.elf] Error 1

Thank you!

case sensitivity issue under linux

There is a missing .lower() on self.HAL_TYPE in the deleteOriginalEclipseProjectFiles method, line 134. This causes a file or directory not found error under linux as stm32F4xx and stm32f4xx get used interchangeably. I'm attaching a simple patch that worked for me.

patch.txt

CubeMXImporter shebang uses the system python

I'm using https://github.com/yyuu/pyenv to manage multiple python versions on my Mac, and the cubemximporter.py script hard codes the system python into the shebang, i.e.

#!/usr/bin/python

Since lxml is not installed in my Mac system python, the script fails.

Instead, can you use the system environment python to ensure that the correct python executable is used?

#!/usr/bin/env python

New CMSIS Directory Structure

According to the book (and the script), there are changes to the directory structure that is not compatible anymore. The book and the script used the following directory structure:

Project Root
    |_ Inc
    |_ Src
    |_ Drivers
        |_ CMSIS
            |_ Include
            |_ Device
        |_ STM32XX_HAL_Driver

The new directory structure for CubeMX is as follows:

Project Root
    |_ startup
    |_ Core
        |_ Inc
        |_ Src
    |_ Drivers
        |_ CMSIS
            |_ Device
                |_ ST
                    |_ STM32xxF4xx
                        |_ Source
                            |_ Templates
                        |_ Include
            |_ Include
        |_ STM32xx_HAL_Driver
            |_ Src
            |_ Inc
                |_ Legacy

I've seen this structure with Nucleo F411RE. I'm not sure if it's a universal directory structure change, or is only applicable for this board. If it's a universal change, I modified the script to make sure it runs properly.

If the directory structure has changed universally, is it okay for me to submit a pull request for this?