GPDSC to GCC Makefile converter for ARM

Hi,

I wanted to be able to use the original STM32CubeMX tool
for generation of initialization code, and skeleton of 
the firmware, and be able to continue further development
in the fully open GCC environment in Linux.
Unfortunately, Cube does not generate the GCC Makefile.
For "Other Toolchains" it generates the GPDSC file.

After checking the contents of that file, I've managed 
to prepare a simple Python script, which parses it and
generates the simplistic Makefile.

You should run:
$ gpdsc2mak.py your_project.gpdsc
and you'll get the Makefile generated.
However before you do it, you should adjust the line:

extras="-mthumb -mcpu=cortex-m3 --specs=nosys.specs -D STM32L100xC -T STM32L100RCTx_FLASH.ld -g "

in the script. I have used the above line for my simple
design compiled for STM32L100 Discovery board.

The current version of the script is just a "proof
of the concept". The Makefile contains only a single
rule which calls gcc with all source files and options
needed to compile the final ELF file.
My tests wer done on Debian/Linux, so I've used the
gcc-arm-none-eabi, libnewlib-arm-none-eabi and
gdb-arm-none-eabi packages.

I was able to check it, using the very nice stlink program:
https://github.com/texane/stlink

To allow any user to access the STLink device, I have created
the following UDEV rule:
======= /etc/udev/rules.d/75-stlink.rules ===============
ATTR{idVendor}=="0483", ATTR{idProduct}=="3748", MODE="666" 

(well, it would be better to create a group of users for 
hardware development and grant the access only to members of this
group, but it was done on my small private machine...)

Then i started the "st-util" program in one console,
and then, in the another console, the arm-none-eabi-gdb program
in the directory, in which the program was compiled:
$ arm-none-eabi-gdb prog 

After that I connected to the st-util from gdb:
(gdb) target remote localhost:4242
Remote debugging using localhost:4242
Reset_Handler () at Drivers/CMSIS/Device/ST/STM32L1xx/Source/Templates/gcc/startup_stm32l100xc.s:83

then loaded the firmware to the STM32:
(gdb) load
Loading section .isr_vector, size 0x13c lma 0x8000000
Loading section .text, size 0xe7f0 lma 0x800013c
Loading section .RamFunc, size 0x2f8 lma 0x800e92c
Loading section .rodata, size 0x74 lma 0x800ec24
Loading section .ARM, size 0x8 lma 0x800ec98
Loading section .init_array, size 0x8 lma 0x800eca0
Loading section .fini_array, size 0x4 lma 0x800eca8
Loading section .data, size 0x43c lma 0x800ecac
Loading section .jcr, size 0x4 lma 0x800f0e8
Start address 0x800e5f0, load size 61676
Transfer rate: 7 KB/sec, 5139 bytes/write.
(gdb) 

and all the debugging functions were available.

I hope, that the above description may be helpfull 
for somebody, who wants to do ARM development on Linux
without using huge, proprietary tools.

With best regards,
Wojtek

Well, I've forgotten to write, that the PUBLIC DOMAIN sources of my
script are available on the alt.sources group (subject: 
"Converter from GPDSC file to GCC Makefile for ARM development")
or directly at https://groups.google.com/forum/#!msg/alt.sources/uxOBz90oNqk/rdhWIRW1GwAJ
(Remember to vie it as "original" to be able to obtain the
uncorrupted SHAR archive).

With best regards,
Wojtek


Dnia 12.03.2016 (Wojciech M. Zabo&#322;otny) <wzab@ise.pw.edu.pl> <> napisa&#322;/a:
> Hi,
>
> I wanted to be able to use the original STM32CubeMX tool
> for generation of initialization code, and skeleton of 
> the firmware, and be able to continue further development
> in the fully open GCC environment in Linux.
> Unfortunately, Cube does not generate the GCC Makefile.
> For "Other Toolchains" it generates the GPDSC file.
>
> After checking the contents of that file, I've managed 
> to prepare a simple Python script, which parses it and
> generates the simplistic Makefile.
>
> You should run:
> $ gpdsc2mak.py your_project.gpdsc
> and you'll get the Makefile generated.
> However before you do it, you should adjust the line:
>
> extras="-mthumb -mcpu=cortex-m3 --specs=nosys.specs -D STM32L100xC -T STM32L100RCTx_FLASH.ld -g "
>
> in the script. I have used the above line for my simple
> design compiled for STM32L100 Discovery board.
>
> The current version of the script is just a "proof
> of the concept". The Makefile contains only a single
> rule which calls gcc with all source files and options
> needed to compile the final ELF file.
> My tests wer done on Debian/Linux, so I've used the
> gcc-arm-none-eabi, libnewlib-arm-none-eabi and
> gdb-arm-none-eabi packages.
>
> I was able to check it, using the very nice stlink program:
> https://github.com/texane/stlink
>
> To allow any user to access the STLink device, I have created
> the following UDEV rule:
>======= /etc/udev/rules.d/75-stlink.rules ===============
> ATTR{idVendor}=="0483", ATTR{idProduct}=="3748", MODE="666" 
>
> (well, it would be better to create a group of users for 
> hardware development and grant the access only to members of this
> group, but it was done on my small private machine...)
>
> Then i started the "st-util" program in one console,
> and then, in the another console, the arm-none-eabi-gdb program
> in the directory, in which the program was compiled:
> $ arm-none-eabi-gdb prog 
>
> After that I connected to the st-util from gdb:
> (gdb) target remote localhost:4242
> Remote debugging using localhost:4242
> Reset_Handler () at Drivers/CMSIS/Device/ST/STM32L1xx/Source/Templates/gcc/startup_stm32l100xc.s:83
>
> then loaded the firmware to the STM32:
> (gdb) load
> Loading section .isr_vector, size 0x13c lma 0x8000000
> Loading section .text, size 0xe7f0 lma 0x800013c
> Loading section .RamFunc, size 0x2f8 lma 0x800e92c
> Loading section .rodata, size 0x74 lma 0x800ec24
> Loading section .ARM, size 0x8 lma 0x800ec98
> Loading section .init_array, size 0x8 lma 0x800eca0
> Loading section .fini_array, size 0x4 lma 0x800eca8
> Loading section .data, size 0x43c lma 0x800ecac
> Loading section .jcr, size 0x4 lma 0x800f0e8
> Start address 0x800e5f0, load size 61676
> Transfer rate: 7 KB/sec, 5139 bytes/write.
> (gdb) 
>
> and all the debugging functions were available.
>
> I hope, that the above description may be helpfull 
> for somebody, who wants to do ARM development on Linux
> without using huge, proprietary tools.
>
> With best regards,
> Wojtek