stm32duino core with System Workbench for bluepill

Rick, sorry, i didnt want to say that the other one is better, i just pointed as an alternative solution for not copying the sources.
I really appreciate your work.

Oh, and i also have the system workbench plugin, these 2 plugins seem to coexist peaceful :P

Steve

Which one is your personal preference ?

My preference is Eclipse C++ IDE for Arduino.
The reason: no file copy is needed, the user is flexible by choosing either Arduino IDE or Eclipse IDE without any additional effort.

Thanks

How to set up the eclipse to work with chines ST-link V2 clone to and a stm32f103 to debugg ?
It work with the nucelo64 board with the st-link onboard

stevestrong wrote:My preference is Eclipse C++ IDE for Arduino.
The reason: no file copy is needed, the user is flexible by choosing either Arduino IDE or Eclipse IDE without any additional effort.

There is a blue pill version but it has not been fully merged with the repo and there isnt a boards manager package for it ( and wont be for some tme)

Hi
Very interesting project (bluepill). I used your project files with the latest System Workbench (Nov 2016) and although it compiled and linked (after the utoa issue) the board (a jc66_coreboard) would not enumerate under USB (“device not recognised ….”).
I thought this might be down to using fairly old ArduinoSTM32 bluepill files with the newer System Workbench so I created a new bluepill_2 directory structure using your existing bluepill layout and followed it exactly but using the lastest ArduioSTM32 files. This failed to build with two issues which I have now resolved:
1) The usual utoa
2) unresolved reference to _init

The 2nd issue turned out to be located in a startup file (start_c.c if I remember correctly). Your bluepill startup file had a dummy _init() {asm NOP} but mine, copied from lastest ArduinoSTM32, did not. My question is : Did you create this dummy _init function in the startup file OR was it always in the original ArduinoSTM32 files and has since been removed. If the latter do you know why it was removed ?

And finally, although your bluepill project successfully finds the openocd cfg file (jc66_coreboard.cfg) in the bluepill project directory mine does not. I’ve checked the file exists and in System Workbench I’ve selected “local script” and checked the name is correct but it always returns to “SCRIPT NOT FOUND”. When I start openocd the error message displays the AC6-plugin-stboard-scripts directory and if I copy jc66_coreboard.cfg to this directory everything works as it should. But I can’t get it to work from the local project directory.

What was the purpose of copying over the Platform.txt and Boards.txt files. Are not these redundant in System Workbench?

Anyway, great work, I’m indebted.

robertkendrick wrote:What was the purpose of copying over the Platform.txt and Boards.txt files. Are not these redundant in System Workbench?

Looking at detail of the _init() function we see it is provided by newlib if we were linking with the stdlib libraries.
0800328c <_init>:
800328c: b5f8 push {r3, r4, r5, r6, r7, lr}
800328e: bf00 nop
8003290: bcf8 pop {r3, r4, r5, r6, r7}
8003292: bc08 pop {r3}
8003294: 469e mov lr, r3
8003296: 4770 bx lr


Thanks for taking the time to write this.

Yes, I was running the System Workbench compiler. So, as usual, most of my problems were self inflicted.

Point also taken about the openocd cfg file. I had searched the project files (the xml) and puzzled as to why there were no mention of debugging tools and settings. Assume they are setup via eclipse plugins.

hi all,

i’m using eclipse (actually without Sloeber) i’m setting the defines by manually defining them using platforms.txt and boards.txt as a reference. tedious but it works.

ot: >> it isn’t system workbench either it is gnu arm eclipse http://gnuarmeclipse.github.io. looking at the first post, i think system workbench is literally a better setup to work in and after all that is created by ST itself if i’m right about it. gnu arm eclipse is in perspective a ‘public 3rd party effort’, the environment is possibly similar to system workbench, the developer(s) of gnu arm eclipse developed several stm32 code ‘generators’ for creating blinky projects for some non st boards, notably from olimex, has a qemu emulator that sport several boards some from olimex and targets stm32 f1 and f4 targets but the features are incomplete (e.g. i think interrupt priorities currently won’t work) and hence only basic emulation functionality) and segger j-link and openocd connectivity <<

here is how i’ve tixed the issues

utoa() issue

as mentioned by rick
https://github.com/arduino/Arduino/pull/4830/files
this is simply because the later gcc versions delivered a utoa() function that has a somewhat different declaration

in my local copy of STM32F1/cores/maple/itoa.h
#define GCC_VERSION (__GNUC__ * 10000 \
+ __GNUC_MINOR__ * 100 \
+ __GNUC_PATCHLEVEL__)

#if !(GCC_VERSION > 40902)
extern char* utoa( unsigned long value, char *string, int radix ) ;
#endif

ag123 wrote:…
the only trouble is that this is part of the variant start up codes, hence, we’d need to patch every variant if we want to fix the missing _init()

thanks rick,
i did find init() in STM32F1/variants/maple_mini/wirish/boards.cpp
i.e. it is part of the variant

however, i can’t figure out how premain() which calls init()
gets patched into __preinit_array

apparently in the newlib code the function __libc_init_array()
https://github.com/eblot/newlib/blob/ma … isc/init.c
is defined as such:
/* Handle ELF .{pre_init,init,fini}_array sections. */
#include <sys/types.h>

#ifdef HAVE_INITFINI_ARRAY

/* These magic symbols are provided by the linker. */
extern void (*__preinit_array_start []) (void) __attribute__((weak));
extern void (*__preinit_array_end []) (void) __attribute__((weak));
extern void (*__init_array_start []) (void) __attribute__((weak));
extern void (*__init_array_end []) (void) __attribute__((weak));

extern void _init (void);

/* Iterate over all the init routines. */
void
__libc_init_array (void)
{
size_t count;
size_t i;

count = __preinit_array_end - __preinit_array_start;
for (i = 0; i < count; i++)
__preinit_array_start[i] ();

_init ();

count = __init_array_end - __init_array_start;
for (i = 0; i < count; i++)
__init_array_start[i] ();
}
#endi

ag123 wrote:
missing _init()

it turns out _init() is possibly intended for shared library initialization (e.g. in linux) and newlib does not ship with that,
http://dbp-consulting.com/tutorials/deb … artup.html
i noted that newlib provides void __libc_init_array() but does not provide _init()

i discussed it in some details here http://www.stm32duino.com/viewtopic.php … =80#p25978

ag123 wrote:however, i can’t figure out how premain() which calls init()
gets patched into __preinit_array

thanks rick, it seemed then that in my case, i missed out to include a lib in my build path, let me check that on my end

wow, i’ve been tracing and tracing and i simply couldn’t figure out where in the ld scripts, assembler files or c functions that premain() somehow gets into init_array

ag123 wrote:thanks rick, it seemed then that in my case, i missed out to include a lib in my build path, let me check that on my end

i run into a problem of ‘fat binaries’ and in an attempt to solve that i set the ld flags
–nostdlib no standard lib
-Xlinker –gc-sections remove unused sections
–specs=nano.specs use newlib-nano

i’m actually building using gcc-arm-none-eabi-6-2017-q1-update, so far it works
however, i get the error _init() is not defined if the above ld options are set
my guess is that –nostdlib overrides –specs=nano.specs and hence _init() is no longer included
however, without –nostdlib the binary size is considerably fatter even if –specs=nano.specs is stated
http://www.stm32duino.com/viewtopic.php … =80#p25978

ok i discovered something about my gcc installation gcc-arm-none-eabi-6-2017-q1-update (this is actually 6.3.1 going by the path names i see)
in the installation folder gcc-arm-none-eabi-6-2017-q1-update/lib/gcc/arm-none-eabi/6.3.1

there are 2 crt*.o files: crti.o and crtn.o
nm crti.o
00000000 T _fini
00000000 T _init


You probably want ‘-nostartfiles’ instead of ‘-nostdlib’.

-nostartfiles lets you provide your own startup code but lets you link with the nano.specs libc stuff.

As far as code bloat goes, you need to spend some time with arm-none-eabi-objdump -CS yoursketch.ino.cpp.elf | less to see what is causing your code to bloat.