I have set up a offline project for the EmBlocks IDE :

http://mbed.org/users/dreschpe/notebook/offline-nucleo-development-with-emblocks/#

The EmBlocks IDE support the stlink-v2 debugger .You can simply download code and have a full featured debugger with your mbed code using gcc and newlib nano out of the box.

Great tool Peter!!

I am new into mbed and Nucleo boards (I do have experience in MCUs from other vendors).

I have run some programs downloading the bin file from the online compiler, but I would like to use emblocks for debugging with the stlink debugger. However I have a NUCLEO-F302R8 board, which does not match the two sample projects that you provided.

Could you build one project for that board?

Thank you

@PakNucleo, you should be easily to just open a project, change a target and adjust the code (probably just main code file).

Hello Martin.

Hello

Is there any change in the memory definition file? Please, mind that I want to debug in EmBlocks.

Thank you.

I forgot to check if the target supports ARM GCC which I believe is the toolchian you want to use in EmBlocks.

You can add GCC (this target should be just copy-paste-edit from the other targets).

Regards,
0xc0170

And how could I do that? Where can I find the other targets? Sorry, I am new into both mbed and EmBlocks.

Actually EmBlocks includes its own ARM "bare metal" GNU compiler. More info here: http://www.emblocks.org/web/features

Thanks

Set up a new project in EM::Blocks for your cpu. This will generate the linker and startup files. Test it with the debugger. Set up a project online and delete the mbed lib. Replace it with mbed-src to get the source of the mbed libs. Export the project for keil. Other exports are not implemented at the moment for the nucleo platform. Unzip the project and copy the cpp and h files into the EM::Blocks project. You can use my project as template. You only need the TARGET_STM/.... path for your cpu. To get the mbed files into the EM:Blocks project use "Add files recursively". You have to change the linker settings to use the C++ libraries. Project's build options ... -> Linker settings -> Categories: Library selection -> Use C++ libraries. Because the mbed source has the cmsis header you can delete the stm32f30x... files and headers that come from the EM::Blocks wizard.

Regards, Peter

I found the issue, in case somebody needs it.

In the file stm32f302cb_flash.ld you need to declare memory as:

MEMORY

{

ROM (rx) : ORIGIN = 0x08000000, LENGTH = 0x10000

RAM (rwx) : ORIGIN = 0x20000194, LENGTH = 0x3E6C

}

----------------------------------

Thank you Peter. I was able to compile in EmBlocks with mbe for F302R8, however, when I try to load/debug the program it get stuck in the file startup_stm32f30x.S after the call of the _start function:

My last STLINK info is:

My last call stack is:

MY last CPU reg info is:

The F302R8 is just 64KB of FLASH and 16 KB of RAM.

I don't know what it could be. Thank you

-----------------

Thank you Peter. I was able to run the simple blink example using mbed on EmBlocks, however, if I try to open a UART (like in the Nucleo_printf example) I get this error messages:

----------------------------------

.\cmsis/core_cm4.h:135:0: warning: "FPU_USED" redefined [enabled by default]

<command-line>:0:0: note: this is the location of the previous definition

src\main.cpp:21:9: warning: "/*" within comment [-Wcomment]

c:/program files (x86)/emblocks/2.20/share/em_armgcc/bin/../lib/gcc/arm-none-eabi/4.7.3/../../../../arm-none-eabi/bin/ld.exe: bin\Debug\Nucleo_f302R8.elf section `.text' will not fit in region `ROM'

c:/program files (x86)/emblocks/2.20/share/em_armgcc/bin/../lib/gcc/arm-none-eabi/4.7.3/../../../../arm-none-eabi/bin/ld.exe: region `ROM' overflowed by 3312 bytes

collect2.exe: error: ld returned 1 exit status

----------------------------------

If I compile in Release mode, of course the program fits and run. How memory demanding is mbed?

I attached my project files so anybody can use it. /media/uploads/PakNucleo/nucleo_f302r8_mbed.rar

It looks like the code is to big for the memory. The ARM compiler code is smaller than the gnu. The ARM linker does a better job most of the time. Quality has a price :-) Do you need a special function of the F302 ? With the F401 you don't run into this problem.

Regards, Peter

The special feature that 302 has and 401 hasn't is the sub 1$ price for manufacturing a series of boards. Actually, the quality vs price ratio is higher in the F302 ic. Other St boards, as the stm32l0 have less memory available , so that should not be the issue.

Of course, using mbed across different boards would be great to reuse code.

Which are mbed memory requirements? I haven't found such info.

Regards.

The mbed lib is written in C++. The C++ runtime is bigger than a plain c runtime. Also mbed is using the big printf with all options. If you use printf, your code will grow noticeable. You can't get a memory map with the online compiler at the moment, but you can produce a memory map with the gnu. There you can see which function is big. The mbed lib is also using the CMSIS system drivers. Code is portable, but because of the level of abstraction this result in a pointer to a pointer ... A simple output to a port pin will end up in multiple calls and add code size. Without this level of abstraction mbed will not portable to all this devices without a lot more work.

If you compare the output of the ARM compiler and the gnu you will see that the gnu code is bigger. The ARM linker is nearly perfect in stiping out unused functions out of the lib-c. The code is also more compact and better optimized. If you will sell a 100.000 series of boards buy the ARM compiler. You will save money if you can use a smaller device. If you only make 100 boards it will be cheaper to use a bigger cpu.

Optimizing code size by hand is a lot of work and time, but you can be better than C++ ;-)

Thank you for your help Peter. I am understanding more and more mbed thanks to you.

The difference betweeen the mbed online compiler size is 13kB vs 55kB of the ARM GCC compiler in release mode for the same project. If I remove the printf calls (and Serial) the bin file shrinks to 46kB (not too much anyway). A similar program using ARM GCC and the SPL library (only C) on EmBlocks instead of using mbed is only 4kB!!

So everything seems to point to mbed in a arm gcc compiler.

Here attached is my Release map file: /media/uploads/PakNucleo/nucleo_f302r8.map

I don't full understand this map file, could you give me a hand on this? Will I face the same issues if I port mbed to eclipse and arm gcc?

Regards.

The interesting things start here :

Memory Configuration

Name Origin Length Attributes

ROM 0x08000000 0x00010000 xr

RAM 0x20000194 0x00003e6c xrw

• default* 0x00000000 0xffffffff

After that we see the interrupt vectors at the ROM start. You see the start address and length of the function or data in hex. The biggest chunk : 0x08003284 0x5244 ... libstdc++_n.a(cp-demangle.o) I think that is the C++ exception handler !

I think there is a map option flag to sort the output by size.

You will see that there are a lot of functions that your program will not use - but the mbed lib has included. The ARM linker will swap this functions. If your code get bigger and you use a lot of functions out of the lib c the difference between the two compiler will shrink. A small C++ program is the worst case for gcc.

Thanks Peter. Sorry, but I didn't find the map option flag for sorting the output by size in EmBlocks.

However I have found two interesting topics about compiling by size for using newlib nano:

http://www.emblocks.org/forum/viewtopic.php?f=23&t=58

http://www.emblocks.org/forum/viewtopic.php?f=23&t=86&p=370&hilit=gcc+newlib+nano#p370

http://www.emblocks.org/forum/viewtopic.php?f=23&t=120&hilit=gcc+newlib+nano&start=10

More from ARM:

http://community.arm.com/groups/embedded/blog/2013/01/21/shrink-your-mcu-code-size-with-gcc-arm-embedded-47

However in our mbed projects those options are fixed:

Is it possible to shrink size using newlib-nano and compiling by size with C++ for med?

You have to click the project setting (Nucleo_f302r8-mbed) to change these settings.

Regards, Edje

You didn't click The project settings, click this line, NOT the debug or release.

Thank you Evert.

If I change in the compiler Settings -> under Compiler flags-> the C++ options and I check "Don't catch exceptions" and "Don't generate RTTI" the program size shrinks from 56k to 46k.

Of course I am using Newlib Nano-branch options.

Which is the size of the code you generate?

Regards

And have you also looked at:

http://www.emblocks.org/forum/viewtopic.php?f=23&t=86

Yes, I do have the same. However the C++ compiled projects (as mbed) are huge on GCC.

The stantard C projects using SPL library are minimal.

I never used C++ for a real embedded project so I don't have much experiences with this.

BTW You can't use LTO with Mbed projects because the Mbed RTOS is not generating LTO compatible code. You will get a lot of assembly errors. I found these problems while I was testing the 3.0 emblocks release with GCC 4.8 and LTO support.

If you have used mbed, then you have used C++.

I hope mbed check this things out, so mbed projects can compile and generate reasonable size files under GCC.

I never used Mbed : )

I don't like mixed projects with c and c++ so I would avoid such projects for "real" projects if I can. I only made an exporter for Mbed and an importer for EmBlocks,

Ok I see. ;)

I think if you could make mbed "usable" within EmBlocks, your platform will get a lot of hype and new users. It is one of the best IDEs out there!!

It is just a matter of tweaking GCC compiler and its options. 55kB file size is not good for a simple program.

I don't understand why it is so large.

Here an example build of the F051 Blinky with RTOS and mixed c/c++:

This is not that big and it is actually running.

It would be nice if the Mbed front-end becomes ready for exporting to EB. Everything is ready only the website front-end not yet. This will set all the options for c and c++ (c++ on file level). I have build this project just right after the import without any tweaking of options.

That is interesting. I have two doubts.

Could you use the printf function from mbed, and see if the file grows? (As Peter Drescher stated).

Could you compile the project I made for the Nucleo F302 board and check the size? /media/uploads/PakNucleo/nucleo_f302r8.rar

Regards

Ps

With "not that big" I mean compared to you, it is still tremendous for blinking two LEDs.

As you can see in the picture, printf is used in the function print_char but the floating point is not enabled.

Right now I'm busy with solving a bug/feature inside GDB for one of the users (GDB is re-building now so coffee time), as soon as I have some time and will give it a try.

Sorry, I didn't realize.

Thank you. I will wait for your answer. If there is anything I can do to help, please, let me know.

I don't know why but your project is pulling in 21K of cp demangle functions on the "verbose_terminate_handlerEv".

I think it has something to do with throw-non-throw mechanisms which are pulled in by the coding style.

.text._ZN9gnu_cxx27verbose_terminate_handlerEv 0x08002694 0x98 e:/_emblock/svn/src/build/share/em_armgcc/bin/../lib/gcc/arm-none-eabi/4.8.4/../../../../arm-none-eabi/lib/armv7e-m\libstdc++_s.a(vterminate.o) 0x08002694 gnu_cxx::verbose_terminate_handler() .text 0x0800272c 0x5780 e:/_emblock/svn/src/build/share/em_armgcc/bin/../lib/gcc/arm-none-eabi/4.8.4/../../../../arm-none-eabi/lib/armv7e-m\libstdc++_s.a(cp-demangle.o) 0x08007dcc cxa_demangle 0x08007e90 gcclibcxx_demangle_callback