The new utility, named ST2Makefile, is available on https://github.com/baoshi/ST2Makefile

My limited testing shows it works for most example projects in ST’s library package, as well as STM32CubeMX exported projects. One thing needs tweaking could be that some ST’s example project contains duplicated source files. If you receive error message such as “Symbol already defined in XXX” during linking, please check the SRCS section for any duplicated source entries.

The usage is changed a little since CubeMX2Makefile.py, now you should run:

[code light=”true”]
ST2Makefile.py <TrueSTUDIO project location>
[/code]

where you can identify TrueSTUDIO project location by locating “.project” and “.cproject” files inside it.

As usual, some useful resources:

Useful links

ST2Makefile: https://github.com/baoshi/ST2Makefile
ARM GCC: https://launchpad.net/gcc-arm-embedded

My packaged GNU Make for Win32: https://ba0sh1com.files.wordpress.com/2020/09/2c1c9-make.zip

The post TrueSTUDIO STM32 project to GCC Makefile converter appeared first on Digital Me.

UPDATE

Always get update from https://github.com/baoshi/CubeMX2Makefile The code is now based on SW4STM32 project output. Thanks various contributors to make this possible.

Deprived off electronics lab back in Singapore, a Chinese new year holiday here in Shanghai home is perfect for some software projects. I have little exposure with Python but after two days of Googling (through VPN) and copy/paste, a crude CubeMX2Makefile utility is ready, available at https://github.com/baoshi/CubeMX2Makefile (OOP aficionados please forgive my spaghetti styled code. It works is it?)

As the name suggests, the program converts STM32CubeMX project into a GNU Makefile. Here is a mini-HOWTO:

1. Create a STM32CubeMX project, configure pins, peripherals and MiddleWare, then edit project settings as follows: (choose SW4STM32 instead of TrueStudio in the picture below)

   

   Make sure the Tool/IDE selection is TrueSTUDIO 4.3.1 (as of STM32CubeMX 4.6.0), and note down the “Toolchain Folder Location”. I found it necessary to empty the old “Toolchain Folder” before each code generation, otherwise the project file just keep growing regardless of settings (this could be a bug in STM32CubeMX). See update below.

2. Download the project from the Github repo below, extract files to a folder, say “C:CubeMX2Makefile”. Install Python 2.7 Win32 from www.python.org

   [code light=”true”]
   c:CubeMX2Makefile>dir /b
   .gitattributes
   .gitignore
   CubeMX2Makefile.py
   CubeMX2Makefile.tpl
   readme.md
   [/code]

3. From command prompt, execute CubeMX2Makefile.py, e.g,

   [code light=”true”]
   c:CubeMX2Makefile>CubeMX2Makefile.py R:411ProjTestF4
   File created: R:411ProjTestF4Makefile
   [/code]

4. Cd into “Toolchain Folder Locaiton”, make project, i.e.,

   [code light=”true”]
   R:411ProjTestF4>make
   …
   arm-none-eabi-size build/TestF4.elf
   text data bss dec hex filename
   5876 12 1056 6944 1b20 build/TestF4.elf
   arm-none-eabi-objcopy -O ihex build/TestF4.elf build/TestF4.hex
   [/code]

   Refer to blog and below links for ARM GCC and make utility installation. It will be much easier to import the Makefile project into Eclipse CDT for code editing and debugging.

Useful links

CubeMX2Makefile: https://github.com/baoshi/CubeMX2Makefile

STM32Cube: http://www.st.com/stm32cube

ARM GCC: https://launchpad.net/gcc-arm-embedded

My packaged GNU Make for Win32: https://ba0sh1com.files.wordpress.com/2020/09/2c1c9-make.zip

The post STM32CubeMX GCC Makefile project appeared first on Digital Me.

1. The device’s MISO (or DOUT) pin uses open-drain output. This is usually true because open-drain allows multiple SPI slaves to share the same MISO line.
2. In the communication protocol, the slave device always waits for the master to send fixed number of bytes (commands) from  MOSI, then returns a fixed number of bytes to MISO. Some devices which transmit and receive data simultaneously cannot be used in half-duplex mode.
3. The slave ignores whatever appears on the MOSI pin when transmitting data to the master. This is usually not mentioned in the datasheet. However, if the slave device mandates a CS or STROBE signal to be asserted at the beginning of each data exchange, we can usually assume this is true. Reason being that the slave device is using CS to reset its internal state rather than always listening and parsing command byte(s) from the master.

Half-duplex wiring of STM32 SPI is as follows:

In particular, MOSI and SCK are configured as “Alternate Function” mode. Hardware CS (NSS) management must be disabled and user shall manually control CS using GPIO output. R2 is pull-up resistor as required by SPI. R1 works as protection resistor in case STM32 MOSI pin somehow enters into push-pull output mode. The SPI setup code is as follows:

[code]
void SPI_Configure()
{
SPI_InitTypeDef SPI_InitStructure;
// Enable SPI1 clock
RCC_APB2PeriphClockCmd(RCC_APB2Periph_SPI1, ENABLE);
// SPI1 configuration
SPI_InitStructure.SPI_Direction = SPI_Direction_1Line_Tx; // Initially Tx
SPI_InitStructure.SPI_Mode = SPI_Mode_Master;
SPI_InitStructure.SPI_DataSize = SPI_DataSize_8b;
SPI_InitStructure.SPI_CPOL = SPI_CPOL_High; // Clock steady high
SPI_InitStructure.SPI_CPHA = SPI_CPHA_2Edge; // Data write on rising (second) edge
SPI_InitStructure.SPI_NSS = SPI_NSS_Soft;
SPI_InitStructure.SPI_BaudRatePrescaler = SPI_BaudRatePrescaler_64;
SPI_InitStructure.SPI_FirstBit = SPI_FirstBit_LSB;
SPI_InitStructure.SPI_CRCPolynomial = 7;
SPI_Init(SPI1, &SPI_InitStructure);
SPI_RxFIFOThresholdConfig(SPI1, SPI_RxFIFOThreshold_QF);
SPI_Cmd(SPI1, ENABLE);
}
[/code]

Line 7 sets the SPI peripheral to half-dulex transmission mode. Line 17 sets the SPI FIFO buffer threshold to quarter full. This is new in STM32F0 with 4-byte SPI FIFO buffer. SPI_RxFIFOThreshold_QF meaning that the SPI_I2S_FLAG_RXNE flag will be set as soon as 1 byte (quarter buffer) is shifted into receiving FIFO. SPI master sending data to slave is as simple as:

[code]
void send_byte(uint8_t val)
{
GPIO_ResetBits(GPIOA, GPIO_Pin_4); // CS low
while (SPI_I2S_GetFlagStatus(SPI1, SPI_I2S_FLAG_TXE) == RESET); //wait buffer empty
SPI_SendData8(SPI1, val);
while (SPI_I2S_GetFlagStatus(SPI1, SPI_I2S_FLAG_BSY) == SET); //wait finish sending
GPIO_SetBits(GPIOA, GPIO_Pin_4); // CS high
}
[/code]

The following code demonstrates master sends 1 byte command to slave and reads 1 byte back.

[code]
uint8_t send_and_read_byte(uint8_t cmd)
{
uint8_t result;
GPIO_ResetBits(GPIOA, GPIO_Pin_4); // CS low
while (SPI_I2S_GetFlagStatus(SPI1, SPI_I2S_FLAG_TXE) == RESET); //wait buffer empty
SPI_SendData8(SPI1, cmd);
while (SPI_I2S_GetFlagStatus(SPI1, SPI_I2S_FLAG_BSY) == SET); //wait finish sending
// Read receiving FIFO until it is empty
while (SPI_GetReceptionFIFOStatus(SPI1) != SPI_ReceptionFIFOStatus_Empty)
SPI_ReceiveData8(SPI1);
SPI_BiDirectionalLineConfig(SPI1, SPI_Direction_Rx);
while (!(SPI1->SR & SPI_I2S_FLAG_RXNE)) ; // wait data received
GPIO_SetBits(GPIOA, GPIO_Pin_4); // CS high
SPI1->CR1 |= SPI_Direction_Tx; // Set Tx mode to stop Rx clock
result = SPI_ReceiveData8(SPI1);
return result;
}
[/code]

Immediately after one byte is sent, the program empties all stale data in the FIFO (line 9, 10), then sets SPI direction to receiving mode (line 11). As soon as SPI enters into receiving mode, STM32 will continuously generate clock on SCK pin until receiving mode is disabled. Along with the clock toggling, data are shifted from MOSI pin into receiving FIFO, and SPI_I2S_FLAG_RXNE flag is set once 1 byte of data is received (line 12). The program then disables CS (line 13, to disable slave output) and switches SPI back to transmitting mode (line 14, to stop the clock). These two steps must be executed fast enough before the next clock is sent out to prevent the slave device enter into any undefined state. Timing is very critical here especially when SPI clock is high. To receive multiple bytes from the slave, put line 9-15 into a loop but disable CS only after all data are read. Important thing is to always disable receiving mode immediately after FIFO is quarter full, and verify using a scope or logic analyser to ensure exact 8 clocks are send in-between each reading.

The post HOWTO: Use STM32 SPI half duplex mode appeared first on Digital Me.

Background information

STemWin is available at http://www.st.com/web/en/catalog/tools/PF259225 (Do not complain if the link does not work. ST did great SEO job by changing URL regularly. Google is your friend…). Basically STMicroelectronics licensed it from SEGGER and distribute the library in binary form. At the time I’m writing this post STemWin is at verison 1.1, corresponding to SEGGER emWin v5.22. The license term for STemWin is pretty obscure according to my English standard. But as far as I can interpret the usage of STemWin with STM32 micro controllers is free for both commercial or non-commercial cases. SEGGER emWin is also available from NXP, carrying a similar license, or from Keil MDK-ARM. The later requires a professional license which is far deeper than my pocket.

The Truly LCD costs as low as $4  from taobao. I suspect it is some sort of left-overs from mobile phone manufacture. The seller told me he has 10K+ ready stock. The LCD controller is Himax HX8352C. I erroneously assume that emWin supports HX8352 and HX8352B so it should support HX8352C, until I wire up the LCD and the garbage churns out.

As a sincere RTFM user I looked into STemWin documentation. There is a chapter “29.7.20 GUIDRV_Template – Template for a new driver”, roughly 1/3 page long, talking about how to write a display driver. Don’t blame SEGGER or ST for not providing more details. SEGGER charges €1,100 for the source code of a driver. They need to make a profitable business after all. And the 1/3 page paragraph proves to be very useful indeed.

For impatients or who want to criticise my code straight away, please jump to GUIDRV_HX8352C

Bare metal LCD driver

Before interfacing the LCD panel with emWin, it is always necessary to make the panel work with bare metal code first. My testing hardware is on a STM32F103RCT6 minimalism board. The reason I choose a 64-pin RCT6 instead of a 100-pin monster is that I wanted to test GPIO to LCD driver performance. If a 100-pin device is used, we can drive LCD using FSMC port and it will be much easier. My LCD wiring is as follows :

We’ll need to implement the following functions for hardware accessing:

void lcdReset(void);
void lcdInit(void);
void lcdWriteData(uint16_t data);
void lcdWriteReg(uint16_t data);
uint16_t lcdReadData(void);

As the name suggests, these functions handles LCD reset, LCD initialization and read/write data/register from/to the LCD controller. Implementation of these functions is as simple as following the LCD datasheet. My actual implementation is within the GitHub repository linked below. A simple main() function to test the LCD interface:

// Note: This code assumes 16-bit parallel interface and HX8352C controller.
void main(void)
{
    lcdInit(); // Internally calls lcdReset()
    lcdWriteReg(0x0002);
    lcdWriteData(0x0000);
    lcdWriteReg(0x0003);
    lcdWriteData(0x0000);
    lcdWriteReg(0x0006);
    lcdWriteData(0x0000);
    lcdWriteReg(0x0007);
    lcdWriteData(0x000);
    // Write data
    lcdWriteReg(0x0022);
    lcdWriteData(0xFFFF);
    while(1) {}
}

This shall display a white dot at coordinate (0, 0). If it works, congratulations you’re halfway towards success. If it doesn’t, look into the controller datasheet and debug your software/hardware.

Looking into a template driver

STemWin comes with some sample codes for various ST development boards, but display driver is not one of them. Since the limited documentation actually tells us the sample driver is called GUIDRV_Template, try Google “GUIDRV_Template.c” will lead you to the same file at ST forum. (I try not to host the file here as I’m not sure about its license.) Another way to obtain this file is download the trial version of MDK-ARM, as bonus you’ll have all other emWin samples.

Now look at the template driver. The only thing it exposes to the public is a structure GUIDRV_Template_API, which consists a number of function pointers:

/*********************************************************************
*
* GUI_DEVICE_API structure
*/
const GUI_DEVICE_API GUIDRV_Template_API = {
    //
    // Data
    //
    DEVICE_CLASS_DRIVER,
    //
    // Drawing functions
    //
    _DrawBitmap,
    _DrawHLine,
    _DrawVLine,
    _FillRect,
    _GetPixelIndex,
    _SetPixelIndex,
    _XorPixel,
    //
    // Set origin
    //
    _SetOrg,
    //
    // Request information
    //
    _GetDevFunc,
    _GetDevProp,
    _GetDevData,
    _GetRect,
};

The documentation actually tells us that among all the functions , we only need to adapt the _GetPixelIndex and _SetPixelIndex. That is more or less correct. I show you how.

Quick and Dirty emWin driver

Go to GUIDRV_Template.c, find _GetPixelIndex and _SetPixelIndex. SEGGER already put the comments there saying “Write into hardware … Adapt to your system”, so adapt them as follows

// Note: Pseudo code below, adapt to your implementation
static void _SetPixelIndex(GUI_DEVICE *pDevice, int x, int y, int color)
{
   //Draw_Pixel(x,y,PixelIndex);
   // Move cursor
   lcdWriteReg(0x0002);
   lcdWriteData(HIBYTE(x));
   lcdWriteReg(0x0003);
   lcdWriteData(LOBYTE(x));
   lcdWriteReg(0x0006);
   lcdWriteData(HIBYTE(y));
   lcdWriteReg(0x0007);
   lcdWriteData(LOBYTE(y));
   // Write data
   lcdWriteReg(0x0022);
   lcdWriteData(color);
}

static unsigned int _GetPixelIndex(GUI_DEVICE *pDevice, int x, int y)
{
    U16 reads[3];
    //PixelIndex = ili9320_GetPoint(x,y);
    // Move cursor
    lcdWriteReg(0x0002);
    lcdWriteData(HIBYTE(x));
    lcdWriteReg(0x0003);
    lcdWriteData(LOBYTE(x));
    lcdWriteReg(0x0006);
    lcdWriteData(HIBYTE(y));
    lcdWriteReg(0x0007);
    lcdWriteData(LOBYTE(y));
    // Start read data
    lcdWriteReg(0x0022);
    lcdReadData(reads[0]);
    lcdReadData(reads[1]);
    lcdReadData(reads[2]);
    // Pack RGB into RGB565, see HX8352C datasheet for 16-bit interface read
    PixelIndex = ((reads[1] & 0xF800) | ((reads[1] & 0x00FC) << 3) | (reads[2] >> 11));
}

To let emWin use the template driver, LCDConf.c must be provided. Sample LCDConf.c can be found inside STemW

in folder, modify LCD_X_Config like this:

....
//
// Physical display size
//
#define XSIZE_PHYS 240
#define YSIZE_PHYS 400
....
void LCD_X_Config(void)
{
    ....
    pDevice = GUI_DEVICE_CreateAndLink(GUIDRV_Template_API, GUICC_565, 0, 0);
    ....
}

....

int LCD_X_DisplayDriver(unsigned LayerIndex, unsigned Cmd, void * pData)
{
    ....
    switch (Cmd)
    {
    case LCD_X_INITCONTROLLER:
    {
        lcdInit();
        return 0;
    }
    ....
    }
    ....
}

Added other necessary files (GUIConf.c, various header files, etc) into project, write a test main as

void main(void)
{
    ....
    // Setup STM32 system (clock, PLL and Flash configuration)
    SystemInit();
    // Necessary for STemWin to authenticate that it is runing on STM32 processor
    RCC_AHBPeriphClockCmd(RCC_AHBPeriph_CRC, ENABLE);
    GUI_Init();
    GUI_DispString("Hello world!");
    ....
}

And you’re golden.

Re-organisation code

Thanks for following me till this point. I must apologise that I did not prepare any ready examples  that you can modify on top. I deem providing such an example not necessary because all what we’ve been doing is “quick and dirty”. If you look into the SEGGER provided drivers and examples, you will find that the hardware interfacing, the LCD drawing primitives and the LCD panel configuration are nicely segregated into different modules. This enables SEGGER to distribute the LCD drawing primitives as hardware independent binary “drivers” without restrict the actual panel and hardware connectivity. Although I have no intention to distribute the custom driver in binary form, adopting such architecture will ensure optimal readability and portability.

Let’s go back look at the GUIDRV_Template_API structure. We have already implemented the drawing functions. The remaining 4 functions, namely _GetDevFunc, _GetDevProp, _GetDevData, _GetRect, are critical for emWin core to query necessary information from the driver. The reference implementation in GUIDRV_Template.c involves a lot of runtime settings, e.g., VRAM, panel dimension and orientation, so that user is able to configure the binary driver using external code. Since I’m working on a single panel and I’m open source,  these settings can be hard-coded (SEGGER called it compile-time). With some debug tracing it is not hard to figure out how these functions are called by emWin, and a calling digram of emWin initialization is as below:

I have organized the functions as SEGGER’s other binary driver, with GUIDRV_HX8352C.c handles all the controller interfacing, LCDConf.c links controller module with the hardware interface, and HX8352C_GPIO handles GPIO hardware access to the LCD controller.

Driver optimization

Now look at the template driver’s drawing functions. We already have _GetPixelIndex and _SetPixelIndex. The remaining 4 functions, _DrawBitmap,  _DrawHLine,  _DrawVLine and  _FillRect, are implemented as repeatedly calling  _GetPixelIndex and _SetPixelIndex, which is very inefficient. The correct way of writing these functions is to utilize the LCD controller’s hardware clipping mechanism, and fill GRAM directly. 

A lower level of optimization targets at improving GPIO driving efficiency. For this part I have referenced Andy Brown’s excellent stm32plus library. Most GPIO driving functions are implemented as ARM assembly to ensure correct timing. Andy further introduced a way of fast GPIO writing by utilizing data already on the databus and toggle WR signal repeatedly. This is very useful when doing block filling or line drawing. When all these optimization I have archived 8,846,000 pixel/second filling rate with 72MHz processor clock.

Performance can be further enhanced with a higher pin count STM32 processor using FSMC port access.

GUIDRV_HX8352C

The source for this driver is available at GitHub. Several notes:

1. Demo application is from SEGGER.
2. The building environment is Eclipse + GNU Make + ARM GCC, as described in my previous blog.
3.  The STM32 development board is from taobao. I choose this because it uses 4 wire SWD interface, saving many I/O pins.
4. Theoretically the driver supports emWin “multi-layer” or “multi-display”. But I have not tested it yet.
5. Panel orientation is hard-coded in LCDConf.h, to maintain the compatibility with other emWin drivers.
6. Due to the limited LCD GRAM and RAM in STM32 processor, not all emWin examples are usable. The video below shows those I’ve been able run on a STM32F103RCT6.

The post HOWTO: Write a display driver for SEGGER emWin appeared first on Digital Me.

While lacking of choice is not always a real engineering problem, having too many choices is usually  more troublesome. My filtering for 64-100 pin devices resulted in 1638 devices from 17 manufactures… After much 1 second consideration I finally quickly made a decision. The winner is — STM32 ARM Cortex-M series. At the price point comparable to Microchip or Atmel’s 8-bit processor, I can jump onto 32-bit ARM development, how “IN” it is!

But the road that follows is not as smooth as I had imagined. STmicroelectronics has labelled themselves to be a “Hardware” manufacture so that they can excuse themselves from providing a usable compiler. While they do offer downloads of development tools from reputable vendors such as IAR or Keil, those tools are either “crippled” edition or time limited ware. I then spend several days looking for a guide to setup free or opensource ARM development tool-chain. There are quite a number of good resources online, for example, here, here and here. I’m not going to write “Yet Another …”, just document my approaches here, for note taking purposes.

Mini-TOC

1. Development Platform
2. Command Line Tools
3. Project Folder
4. Project Template
5. Eclipse IDE
6. Import STM32 Project
7. Debugging in Eclipse
8. Eclipse Plugins
9. Downloads

Development Platform

My toolchain installation is on Windows 7. I have test it on both 32-bit and 64-bit editions. I have no plan to do development on Linux or Mac OSX yet, mainly because my other EDA tools are only available in Windows.

Command Line Tools

Compiling program from the command line is probably the best experience to understand the compiler tools and the interaction among them. Most online resources recommend Sourcery G++ Lite as the compiler. I did try this and it works great. However Sourcery is not fully open source and I do not like the fact that you have to signup at Mentor to download it. I use the GNU tools for ARM, because:

1. It is fully open-source.
2. It is actively maintained by ARM employees.
3. It contains hardware float support (which is available on STM32F4) so more future-proof.

I download the Windows ZIP package and extract it to C:Appsarmgcc. (C:Apps is the folder where I usually keep programs that do not need to be installed). I also add C:Appsarmgccbin to the user PATH.

GNU make utilities are also required. I download the Yagarto Tools package from here. GNU make from here is also usable but I found the one inside Yagarto Tools has better compatibility with many “Linux only” Makefiles. GNU Make utility is required. Win32 version with supporting files is here. I extract all the files to C:Appsbin and add the same to user PATH.

To verify the installation, open a Command Prompt and try these two commands:

1. arm-none-eabi-gcc -v
2. make -v

   

I have heard some “make” utilities which maybe installed by other software such as the WinAVR or Delphi can conflict with the GNU make, so make sure “make -v” gives correct version information as “GNU make 3.81”. Otherwise just rename the make.exe to something else such as “gmake.exe”.

Project Folder

Many development tools, e.g.,  Arduino, MPLab, Atmel Studio, Altium Designer, etc, store user files in its own “workspace” or “project” folder. By default the folders are created under Windows user profile, but I prefer to move them to a central location to ease backup and sync. My central location is “D:workspace”. For STM32 I created a “D:workspaceSTM32” where I put all STM32 related files.
ST Standard Peripheral Library is required for development. I downloaded the STM32F10x flavour and put it under d:workspaceSTM32STM32F10x_StdPeriph_Lib_V3.5.0

Project Template

I tried several STM32 project templates available on the Internet, and finally I decided to make my own. The reason I do not like some templates are:

1. Some templates copy files from ST peripheral library to their own folder. This is only good if ST frequently modify their library interface, or you want to modify ST source code. I would rather keep ST library files in their original location and reference them from my Makefile.
2. Some templates compile all ST peripheral library files into one library archive (.a file). It is pretty wasteful if only part of the library are used. I choose to reference only the used ST library files.
3. Some template organize the Makefile into separate sub-makefiles and include them in the final one. It is good for large project. At currently I would rather use a monolithic Makefile to make life easier.

As I have yet to learn how to create a GitHub account, my project template is attached below.
Explanation for some snippets of the Makefile:

[code firstline=”10″]
######################################
# building variables
######################################
# debug build?
DEBUG = 1
# build for debug in ram?
RAMBUILD = 0
# optimization
OPT = -O0
[/code]

Here I set the variables controlling the build process:

• DEBUG is a general debugging switch. If defined as 0, no debug symbol is generated in the final .elf file.
• RAMBUILD sets where the code is executed. If RAMBUILD = 0, the code is set to execute from Flash (starts from 0x08000000). Otherwise if RAMBUILD = 1, the code is executed from RAM (from 0x20000000). RAMBUILD selects the correct link script and interrupt vector table. It is always preferable to debug in RAM as the on-chip flash has a limited re-write cycle. The compiler will generate an error if RAM is not enough to host the complete program.
• OPT is the optimization switch. Sometimes if RAM is not enough for debugging, use -Os to reduce program size.

[code firstline=”20″]
#######################################
# paths
#######################################
# source path
VPATH = src startup
# firmware library path
PERIPHLIBPATH = ../../STM32F10x_StdPeriph_Lib_V3.5.0/Libraries
VPATH += $(PERIPHLIBPATH)/CMSIS/CM3/CoreSupport
VPATH += $(PERIPHLIBPATH)/CMSIS/CM3/DeviceSupport/ST/STM32F10x
VPATH += $(PERIPHLIBPATH)/STM32F10x_StdPeriph_Driver/src
# Build path
BUILD_DIR = build
[/code]

Here various paths are listed, including the project source code (src and startup), ST peripheral library path and building path (BUILD_DIR). Source codes are located using VPATH directive.

[code firstline=”33″]
# #####################################
# source
# #####################################
SRCS =
main.c
stm32f10x_it.c
system_stm32f10x.c

SRCSASM =
startup_stm32f10x_hd.s

# #####################################
# firmware library
# #####################################
PERIPHLIB_SOURCES =
core_cm3.c
stm32f10x_gpio.c
stm32f10x_rcc.c
[/code]

I list all the used source files here. system_stm32f10x.c and stm32f10x_it.c are copied from ST peripheral library. These two files always need modification to suit specific application. Startup code startup_stm32f10x_hd.s is from Attolic TrueStudio.

[code firstline=”87″]
#######################################
# LDFLAGS
#######################################
# link script
ifeq ($(RAMBUILD), 1)
LDSCRIPT = linker/STM32F103VE_ram.ld
else
LDSCRIPT = linker/STM32F103VE_flash.ld
endif
[/code]

These are the link scripts obtained from Atollic TrueStudio and ST peripheral library.
More startup files and link scripts for other STM32 devices are linked at the end of the article.

To compile the project simply type “make” within the project root folder. The Makefile features auto generated dependencies so I do not need to clean the project all the time. At the end of the building process the size of each section is displayed.

Eclipse IDE

Although building program from the command line is probably the best experience to understand the compiler, sticking to the command line only is definitely the stupidest idea (except for some “cool effect” in front of young players). Eclipse is one the the greatest free IDE so I decided to use it.
However Eclipse has become bloatware these days. The current binary package of “Eclipse IDE for C/C++ Developers” is about 130MB, which contains a lot of plugins, such as “Visual C++ support”, that I do not need at all. And you do not have an option to uninstall it! So I choose the bare metal way. Download the “Platform Runtime Binary” package from Eclipse archive (currently version 3.8.2 here). It weights 53MB. Extraction the package to C:Appseclipse-stm32, run eclipse.exe. When workspace location is asked, give “D:workspaceSTM32eclipse”

For the next step, choose “Help”->”Install New Software…”, click the “Add…” button and type in Eclipse CDT site as the picture below (The current settings is for Eclispe 3.8 “Juno”):

Then select “Work with:” CDT and check these packages:

Click “Next”, accept some license nags and a clean bare-metal Eclipse C/C++ development environment is up.

Import STM32 Project

Start Eclipse, choose “File”->”New”->”Makefile Project with Existing Code”, enter as follows:

The project “Blank” is created. A small red cross is displayed at the folder icon. This is because the Eclipse indexer is not able to find all the definitions and prototypes. To fix this, right click the project folder and select “Properties”, in the popup window, select “C/C++ Build->Discovery Options”, change “Complier invocation command” to “arm-none-eabi-gcc”.

Close the Properties window, do a rebuild inside Eclipse (which takes a while as compare to build from command line because Eclipse is scanning into building process). When finished, a “Includes” folder will appear in the project folder. The red cross should go away and all the symbols in the source code shall be able to resolve. (If not, right click project folder, “Index”->”Rebuild”)

Debugging in Eclipse

Programming and Debugging STM32 using UART is possible but clumsy. I’m lucky enough to have a SEGGER J-Link debugger so everything becomes easy. To start program and debug in Eclipse, right click the project, select “Debug As”->”Debug Configurations…”,  select “GDB Hardware Debugging” and press “New Launch Configuration” button, set the parameters at “Main” tab as follows

The debug configuration name is “Debug Blank Flash”, meaning we’re debugging using on-board Dlash. Make sure “Using Standard GDB Hardware Debugging Launcher” is selected at the bottom. For the “Debugger” tab, the following settings are used

BTW I’ll be using SEGGER GDB Server so the “Port number” is 2331. There are other GDB servers such as OpenOCD, but since I’m developing under Windows I’d rather use original SEGGER software.

The “Startup” tab is below

Code inside the two editors are:

[code language=”text”]
monitor speed 30
monitor endian little
monitor reset
monitor speed auto
set remote memory-write-packet-size 1024
set remote memory-write-packet-size fixed
monitor flash download = 1
monitor flash device = STM32F103RC
[/code]

and

[code language=”text”]
tbreak main
monitor reset 0
continue
[/code]

For the “Initialize Command” part, my development board has a STM32F103RCT6 so the “flash device” is set to STM32F103RC.
For the “Run Commands” part, take note I’ve inserted a “monitor reset 0”. I found this is necessary to debug RTOSs such as Chibios (wonder why).

Most of the time it is more convenient to debug inside RAM, provided that the chip has enough RAM for the program. To build a program for RAM debugging, set “RAMBUILD=1” in the Makefile.

A separate debug configuration is necessary for RAM debugging. Simply duplicate a configuration from the previous Flash debugger and configure the “Startup” tab as follows

Similarly the codes are

[code language=”text”]
monitor speed 30
monitor endian little
monitor reset
monitor speed auto
monitor writeu32 0xE000ED08 = 0x20000000
[/code]

and

[code language=”text”]
tbreak main
monitor reset 0
monitor reg r13 = (0x20000000)
monitor reg pc = (0x20000004)
continue
[/code]

The debug configurations can be added to “Favourite” menu for easy launching. But before launching, start “SEGGER J-Link GDB Server”.

Make sure the “BOOT0” and “BOOT1” pin on STM32 are correctly configured when choosing debugging from RAM or Flash.

Eclipse Plugins

There’s a lot of STM32 Eclipse plugins that make life easier. The plugins I use:

1. EmbSysRegView  It shows ARM Cortex registers during debug section. Probably the most useful plugin.
2. StateViewer  It displays important information (Tasks, Queues, Timers) is the program uses FreeRTOS. It is a free plugin but the website asks for your information (which I don’t like). For simplicity the Eclipse software site is “http://www.highintegritysystems.com/StateViewer/“

Plugin I do not use:

1. GNU ARM Eclipse Plug-in This plugin automates ARM development under Eclipse. It uses Eclipse managed build system so user do not need to write a Makefile. The reason I do not use this plugin is because it obscures the building process while I like to have everything in proper control.
2. Zylin Embedded CDT This plugin provides easier settings for hardware GDB. However I do not feel the CDT build-in GDB integration is harder to configure.
3. ST MicroXplorer MicroXplorer is a visual tool for planning and configure STM32 mcu pins. It also generates configuration code automatically. MicroXplorer is distributed as a standalone utility and a Eclipse plugin. The Eclipse plugin seems to slow down Eclipse startup significantly. I use the standalone version.

Downloads

[attachments size=small docid=”656,662,661″]

The post Opensource STM32 development appeared first on Digital Me.