ARM Cortex-M with GCC+Make: Eclipse Integration

Deixe um comentário

In the previous post, we created a simple Makefile project for firmware development using open source tools GCC and Make. This post shows how to integrate this kind of project into Eclipse, once this IDE has the possibility of integration of various types of debugging probes, and not only for Cortex-M cores.

Getting the Eclipse:

The first step is to download Eclipse IDE for C/C++ according to the Java version installed on your system, 64 or 32 bit:

Once downloaded, extract the eclipse folder in C:\tools, or wherever is your tool’s directory.

The Eclipse executable is eclipse.exe inside eclipse directory. The first time that it is executed, it asks for the default projects directory, you can choose for example C:\firmware or other directory.

Getting the code:

If you do not have downloaded the example code yet, get it on https://github.com/brunoeagle/blink-stm32f100 and put it on C:\firmware.

Importing the project into Eclipse:

Actually what is done here is a creation of a eclipse project based on a Makefile project without modifying it at all (which is good for Git or other versioning system), go to File > New > Makefile Projet… :

And then select the example project, and there is no need to set Toolchain, once everything needed for compiling is in the Makefile:

Just click Finish, now the project will be in Eclipse and we are already able to develop and compile(Ctrl+B) inside eclipse, but the problem is that the library and include paths for Eclipse are not configured yet, so it is going to complain about it:

To get rid of this, we need to setup the paths of every library and include that the code makes use of and set the flags for the libraries as well.

Setting the library paths:

To add the paths to the project, just right click on the project and go to Properties. Then go to C/C++ General > Paths and Symbols:

The GCC include paths are (of course it depends on your GCC version):

  • C:\tools\arm-none-eabi-gcc\arm-none-eabi\include
  • C:\tools\arm-none-eabi-gcc\arm-none-eabi\include\c++\6.3.1
  • C:\tools\arm-none-eabi-gcc\arm-none-eabi\include\c++\6.3.1\arm-none-eabi\thumb\v7-m
  • C:\tools\arm-none-eabi-gcc\arm-none-eabi\include\c++\6.3.1\backward
  • C:\tools\arm-none-eabi-gcc\lib\gcc\arm-none-eabi\6.3.1\include
  • C:\tools\arm-none-eabi-gcc\lib\gcc\arm-none-eabi\6.3.1\include-fixed

The ST library include paths are:

  • C:\firmware\STM32Cube_FW_F1_V1.4.0\Drivers\CMSIS\Include
  • C:\firmware\STM32Cube_FW_F1_V1.4.0\Drivers\CMSIS\Device\ST\STM32F1xx\Include
  • C:\firmware\STM32Cube_FW_F1_V1.4.0\Drivers\STM32F1xx_HAL_Driver\Inc

And finally the project paths:

  • C:\firmware\blink-stm32f100\src
  • C:\firmware\blink-stm32f100\src\stm32
  • C:\firmware\blink-stm32f100\src\peripherals
  • C:\firmware\blink-stm32f100\src\application

And we need to put all these paths by clicking on Add… and marking Add to all configurations and languages:

Setting the Symbols:

On Symbols tab, we need to set the same flags that we have set on the Makefile, and that would be:

  • STM32F100xB
  • USE_HAL_DRIVER

Again, mark the Add to all configurations and languages like before:

Click on Apply and Close. There are three more things to do: Righ-click on project and: “Clean Project”, “Index > Rebuild” and press F5 to update the project tree. Now you should get no more errors on missing include files and the autocomplete should work as well.

ARM Cortex-M development using GCC+Make

Deixe um comentário

In every project that I use a Cortex-M microcontroller, the firmware I build using only GCC, Make and Eclipse, but Eclipse I often use only for debugging more easily, the goal with using just GCC and Make is to keep the development as simple as possible. It is possible to develop or compile everything without using any IDE. In this tutorial I’ll show the basics for developing like that, Eclipse integration will be another post I’ll show later.

Developing this way is possible to use Linux, Windows and MinGW environment (and probably OSX), I use both for my daily development, but I’ll use for this example a Windows setup.

Downloading the tools:

  • Toolchain (GCC for ARM) is available at Launchpad: https://launchpad.net/gcc-arm-embedded/+download, just download the last .zip for win32 and will be ok.
  • The Make we’ll use the one bundled in the MinGW-64 project (Unix tools for Windows) on SourceForge on this link, just download the x86_64-6.3.0-release-posix-seh-rt_v5-rev1.7z

Create a directories for the tools:

To keep the tools organized, we’ll create the folowing tools on C:

  • C:\tools
  • C:\tools\binutils
  • C:\tools\arm-none-eabi-gcc

Installing the GCC for ARM:

Extract the gcc-arm-none-eabi-5_4-2016q3-20160926-win32.zip on C:\tools:

And rename it to arm-none-eabi-gcc to simplify:

Installing the Make:

Actually what we are going to do is just extract the mingw-win32.exe executable from MinGW-64 in C:\tools\binutils, there is no need to extracting the whole file. This can be done just by draging the file on the opened folder by using 7-zip:

 

And then rename it to make.exe :

Now the tools that we need are in the right place. Let’s put these directories on the Windows PATH. This is not necessary, but in the Makefile we’ll have to put the whole path for each executable and make a rule for each platform you will work on, it’s your choice, I prefer to put in the Path and of course, making sure that there is no conflicts with other executables/tools.

Adding the tools to Windows PATH:

Add to the Path on Environmental Variables > System Variables > Path the directories of the executables and click ok:

 

Now open a cmd to test the make and the gcc, you should be able to see the following output by issuing the commands make –version and arm-none-eabi-gcc –version:

If it seems the same, the tools are ready to use.

 

The example project:

We’ll assume this simple “board” using the STM32F100C8 for our code, there is only the uC and the led, and guess!, the sample code will blink it:

 

Getting the code and the ST library:

Before getting the library and the code, let’s create a folder to keep the project organized, and the libraries able to be used by another project.

So the folder will be C:\firmware\, of course you should put this folder wherever you want.

  • For the sample code, just clone it  https://github.com/brunoeagle/blink-stm32f100 , clone it in C:\firmware\
  • The library for STM32F1 series from ST is called STM32CubeF1 you can get at the bottom of the page here: http://www.st.com/en/embedded-software/stm32cubef1.html , the actual version is 1.4.0.

After cloning the sample code and extracting the library, the folders should be like this:

  • C:\firmware\blink-stm32f100
  • C:\firmware\STM32Cube_FW_F1_V1.4.0

Test everything by calling “make” inside the blink-stm32f100 folder, if you see an used memories report at the end, all is ok. Like this:

 

Customizing for your own project:

There are a few things to do in order to customize this example for your board/microcontroller, I’ll explain how to do for STM32 and its library from ST, but for other microcontroller it is almost the same, regarding:

  • Linker:

The STM32F100C8 has 64K of FLASH and 8K of RAM. The FLASH starts at the address 0x0800000, and the RAM starts at the address 0x20000000 (check on the datasheet/manual of your microcontroller to be sure of that). These are basically the two things to adjust if your project has another STM32F1 but with different memory configurations. Almost always you’ll find a ready-to-use linker in the library from ST at:

STM32Cube_FW_F1_V1.4.0\Drivers\CMSIS\Device\ST\STM32F1xx\Source\Templates\gcc\linker

For this case, STM32CubeF1 didn’t have a ready-to-use linker for STM32F100C8, but there is one for STM32F100CB, so I copied it to the project folder linker and altered the lines regarding the memory sizes and starting address for:

/* Specify the memory areas */
MEMORY
{
FLASH (rx) : ORIGIN = 0x08000000, LENGTH = 64K
RAM (xrw) : ORIGIN = 0x20000000, LENGTH = 8K
}

  • Startup file:

The .s file is responsible for making the first calls of the firmware, like calling the functions SystemInit for setting up the clocks and __libc_init_array for initializing the firmware’s statics. And not less important, it puts the interrupt service routines (ISR) name functions in the right place on flash addresses (isr_vector). For the STM32F100C8, I’ve used the startup_stm32f100xb.s and not altered it, copied from here:

STM32Cube_FW_F1_V1.4.0\Drivers\CMSIS\Device\ST\STM32F1xx\Source\Templates\gcc

  • Makefile basics:

In the example, until the line 70 of the Makefile, there is all the stuff for detecting the OS, you don’t need to change anything unless you want for some reason, or if your compiler is not in the PATH for example.

In the CFLAGS variable, basically we set the flags for the compiler regarding the processor (-mcpu=cortex-m3) and the flags necessary for the library (-DSTM32F100xB and -DUSE_HAL_DRIVER). Almost all of the times, customizing this project for another microcontroller is basically changing these flags.

In the ASMFLAGS, along with the -mcpu flag, it is possible to pass some flags to the assembler as well.

In LDFLAGS is where the custom linker I said before is set, using the parameter -T./linker/STM32F100XB_FLASH.ld

In INCLUDEPATHS, there is the headers locations used by the source files as #include.

In C_SRC, you must put every source file used by the project, for example, if you want to use the ADC module of this micro, you’ll need to put in this variable the stm32f1xx_hal_adc.c (and uncomment the line #define HAL_ADC_MODULE_ENABLED in the stm32f1xx_hal_conf.h file as well.

In s_SRC, every assembly written file will be placed here, in this case just the startup file (startup_stm32f100xb.s) is added.

Optimization: In front of the debug: and release: there is more options being concatenated to CFLAGS and one of them is the optimization desired for the project, in this case I’m using the -Og because is the best for debugging specially for microcontrollers, but you can put wathever you want, just check the GCC manual here: https://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html

I’m not going in to the details of everything in this Makefile because it will make this post too long, but basically if you want a platform-independent and IDE-independent project, following this guide you should be able to do that.

Next post I’ll show the integration with Eclipse for debugging, and for developing inside of it as well, but not making the project dependent on it.

 

If you have some sugestion, problem or something, just ask here…

AB-Sound: Update

Deixe um comentário

Back from my vacation, I’ve mounted the power supply, and everything is fine with it, all the rails are between the specified, but I didn’t do a full test with the maximum load yet.

Here are some photos:

 

And I’ve mounted some parts of the amplifier board:

  • MCU
  • Display
  • Input selector and P2
  • Crossover and the preamplifier

BUT, I’ve noticed some errors so far:

  • The +-12V/5V regulators have the bypass capacitors connected to the ground, and they are meant to be connected to the output instead, to reduce the noise of the regulator.
  • The volume control was terrible, so I noticed that I did an inverting configuration on them. Result is that volume control wasn’t working as expected and there was a huge crosstalk when selected another input instead of P2.

The display and MCU are working just fine, and I did a simple code to control the volume through the encoders and to select the input. You can check on my github: https://github.com/brunoeagle/ab-sound

Well, I’ve done some bodges correcting the preamp and the the regulators, but there is still a big noise on the output sometimes when I power the thing up.

 

Still investigating, updates to come.

 

Class AB Sound System: AMP PCB

Deixe um comentário

Actually I already finished this board back in November and I’m already testing it, but just to try to keep this series organized, here is the design of the amplifier board:

ab_system_amp_pcb_2d

Note that on every part of the circuit, like in each channel of the power amplifiers, the ground connections are separated and come from the central point in the power supply, so there is an isolated ground connection for:

  • Input connections
  • Digital circuitry including MCU, WiFi, BT and display modules
  • Analog circuitry
  • Left channel amplifier
  • Right channel amplifier
  • Subwoofer amplifier

Here are some 3D prints of the board:

The top layer:

ab_system_amp_pcb_3d

Bottom:

ab_system_amp_pcb_3d_2

 

A 4-layer design would be better for this layout, mainly because of the SDRAM memory interfacing, but in order to reduce the PCB cost, I’ve choosed to make it 2-layer.

 

Class AB Sound System: PSU PCB

Deixe um comentário

Lots of things happening since last month, thankfully is getting better!

Anyway, the PSU pcb design is ready a couple of weeks ago, but just now I’m posting it here:

ab_system_psu_pcb_3d

As you can see, the GND connections of everything on this system is beside of the ‘GND’ label, so there will be the central ground connectors. I don’t usually enable the 3D models on my boards, maybe I should start doing it….

Here is the 2D print:

ab_system_psu_pcb_2d

 

Here is all the Kicad files of this PCB along with the schematics: PSU PCB – Kicad (let’s test this box.com service)

The components arrived last week, but I’m a hurry with a lot of family things and work, but by the end of this week I’ll finish it and send the PCB’s to manufacturing!

Rio Verde de MT – MS – Brazil

Deixe um comentário

dsc05308

There is nothing like being in the woods, or sometimes in a waterfall. These is one example of places next to where I live that’s worth going frequently, specially in the dry season, when the water is always crystal clear, this photo was taken last Sunday. I’ve been beside of this waterfall a few times for camping for 2 or 3 days and it was always awesome. Actually this is a waterfall made by 7 smaller ones before it, and there is other ones on the same river and all of them are as good as this one.

Class AB Sound Sytem: Thermal Management & updates

Deixe um comentário

Before ordering the components, I was reviewing the schematics from the PSU and the Main Board, and I realized that I was forgeting one important thing: Thermal Management. Of course it was in my plans to use a big heatsink for the power amplifiers, but they would have to be bigger than I thought, and I don’t want this, I want this amplifier as small as possible.

So if I won’t put a heatsink of 10kg of aluminum, of course I will have to force the ventilation on this thing, and that will be done via 2 DC fans, and they will be activated when the heatsink reach certain temperature, which will be measured via 2 NTC’s:

ab_system_overall_2

Thermal management added to the main board

At first I thought about controlling the fan speed, but, when the heatsink get hot, it means that the volume is high, so nobody will listen the noise of the fan! Right?! So, just a mosfet channel N to turn ON and OFF is enough:

ab_system_temperature_control

NTC resistors and FET’s to turn the fans on/off

The problem is that the DC fans draw each one around 250mA, and if both of them were turned on with the previous regulator schemes, we’ll exceed the current limit of the AOZ1280 that was regulating the +5V. So the best solution in this case would use two AOZ1280, one for +5V and another for +3.3V, no more linear regulator for the digital part:

ab_system_psu_overall_2

Updated PSU: Added +3.3V switching regulator

Now we have around 1.1A on the 3.3V line with everything turned on and at its maximum consumption, but ok, our AOZ1280 can handle up to 1.2A and this won’t be a problem:

ab_system_psu_3v3

+3.3V regulator

I’ll post the final (I hope so) schematic of the main board and the PSU later this week.

PS: ALWAYS review a design at least three times, because the smallest mistake could ruin your project!

 

Older Entries