Square Thoughts

an engineering student's blog

Archive for the category “ARM”

TI India Analog Design Contest 2011 – Entry Video

This is our entry to the TI India Analog Design contest 2011.

FatFs Library Port for Stellaris EK-LM3S811 Evaluation Board

I have written a port of the ELM-FatFs Generic FAT File System Module for the TI Stellaris EK-LM3S811 Evaluation board which runs on an ARM Cortex-M3 processor. The library is extensively used when connecting SD Cards to embedded systems. It is freely available under the GNU License.

It consists of a File I/O layer and Disk I/O Layer in which the former is constant across all platforms while the latter is specific to a micro-controller.

Disk I/O layer specifies the board pins, clocks and timers which are to be used. The board pins I have used are:

  • SSIClk (Pad No. Eight) connected to SCK Pin of SD Card.
  • SSIRx (Pad No. Ten) connected to DO of SD Card.
  • SSITx (Pad No. Eleven) connected to DI of SD Card.
  • PC4 (Pad No. Five) connected to CS of SD Card.

The files can be downloaded from here. I have also supplied the makefile which takes care of all the compilation tasks provided your toolchain is set up as described here.

Steps to use the files in your project.

  1. Copy all the files in to your project folder.
  2. Include the “ff.h” and “diskio.h” header files in your code.
  3. Refer the ELM – FatFs library reference for writing your program in “main.c”.
  4. Compile the program.

ARM Evaluation Board Bricked?

The feature to remap pins of an ARM processor sounds cool. Ain’t it? But it can be bothersome at times, if you configure pins the wrong way.

The same happened with me which almost bricked my TI Stellaris LM3S811 Evaluation Board. I accidentally configured the JTAG pin, PC0, which was the TCK pin for the JTAG peripheral, to be a GPIO pin. I uploaded the code onto the board and it ran like a charm for my application. But unknowingly, I had done changes which would prevent me from uploading new code on the board. I had bricked it.

The Reason:-

The LM3S811 Evaluation board uses a PC<->USB<->FT2232<->JTAG<->MCU interface. Which basically means, all upload and download of code onto the MCU is done through the JTAG interface. The code reconfigured the JTAG pin to be a GPIO, disabled the JTAG peripheral of the MCU and would not let me upload any code. Even after reset, the pin would lose its JTAG functionality whenever the command to remap would be executed. And this happened way too early in program execution(within microseconds) as the command was the fourth statement in my code. So yes, the computer interface was no longer valid.

What I Tried :-

  1. Knowing other ARM processors could be interfaced using an UART connection, I tried to do the same to upload new code on my device. But a drawback of Stellaris microcontrollers, or infact the Stellaris Bootloader is that it doesn’t allow you to upload code using UART  once the bootloader is put on the device. If you want to use it, it needs to be specified in the startup_<compiler>.c file, which I hadn’t done. So I had no luck.
  2. The Stellaris Board has an onboard 20 pin JTAG connector. I installed OpenOCD to somehow do hardware debugging to stop the controller before it reconfigures the pin. Failed again. Reason being, first, the JTAG would use the the same TCK pin which I had reconfigured, and second, the most important, the JTAG connector on the Stellaris board is OUTPUT only. It can only be used to program or debug another device.
  3. Next I looked up the TI E2E Community (it is great!) for solutions. There I found a post discussing a similar problem. The person instructed to halt the microcontroller immediately after reset and then try. In all MCU, there is time gap between the reset button being pressed and code execution starting. It was a “hit and trial” method (worked in some cases) in which I would erase the flash memory immediately after reset. I tried doing this for almost four hours. But had no luck since the reconfiguration took place very early in my code.
  4. I decided to post my query on the TI E2E Community. I waited for a response for hours and  after some discussion on the forum, was finally blessed with a solution, though not a complete one.

The Solution :- 

In my code, the first statement selected the clock I wanted to use, the second initialized my display adapter, the third configured the pin PC5 and the fourth, and the one which should always be avoided, configured the pin PC0. The main motive was to halt program execution just before the reconfigure takes place. As instructed on the forum, if I could somehow stop the display initialization and come up with an error at that point, program execution would stop. But how to do it? The guy on the forum told me to pull out the display from the board :\

I didn’t do that. Learning how the display was connected to the the MCU, I figured out how it could be done. The display on the Stellaris Eval Board uses the I2C interface to communicate with the processor. I decided to pull the SCL or the clock pin of the I2C low and connected it to GND using a jumper. As there was no clock to the display, it wouldn’t initialize, and program execution would halt.

Job Well Done :- 

I connected the modified board to my computer. Pressed reset, and Eureka! The program execution did stop before the pin could be reconfigured and I successfully uploaded the new code on the board.

Things I Learnt :-

  1. Use the ARM Pin mapping feature cautiously.
  2. Always add a delay before you set up the peripherals in your program code. Atleast 500ms. This might sound silly, but when you need to halt the controller, you can do it in that time or else nothing can be done.
  3. Specifically for all Stellaris microcontrollers, enable UART support in the startup_<compiler>.c file. You never know when you will need it.
  4. The TI E2E Community is far more helpful than the official TI support. The TI support replied to my problem three days after I posted it, it had been fixed by then. You will find some great people on the community.
  5. Never lose hope. It took me two days to finally make it work, again.

Setting up CodeSourcery GNU Toolchain for the ARM in Eclipse Helios on Mac OS X 10.7 Lion

I was introduced to the open source integrated development environment Eclipse  by my friend Shan. Since then, I have shifted all my development routines for Arduino, Python and now ARM onto Eclipse. It is the best IDE I have used so far which supports almost everything, all programming languages, hardwares and toolchains.

The post is a simple walkthrough to making your first ARM project on Eclipse Helios on a Mac running OS X 10.7(the walkthrough is also applicable to previous generation OS X).

I am using Helios. Yes, it is old. A new version is already out. But some of the plugins we need to use, which I shall be explaining later in this post, still run on Helios.

The Basics

Eclipse CDT is a C/C++ development IDE based on Eclipse (which defaults to Java development).

CodeSourcery Lite is GCC-based ARM toolchain which provides all the basic ingredients (compiler, assembler, archiver, linker, libraries, newlib, binutils, etc.) in console based executables. The best thing about CodeSourcery is that they also offer commercial solutions which result in quarterly updates to the Lite tool-chain also. This way you always stay inline with the latest GCC developments.

First let’s have a look at the pre-requisites. You will need the latest version of Apple Developer Tools which include Xcode, Interface Designer, Instruments etc. and can be download from the Mac App Store. It is needed for the initial building of the toolchain which requires gcc, binutils and make. If you do not want to install the Developer Tools package, you will have to download and install these components individually. Google will help you.

Let’s start now.

Step 1 – Install Eclipse

Download and install the Eclipse IDE from http://www.eclipse.org. Eclipse Helios. The download page would provide you with a variety of flavors for the IDE. All of them are useful sometime or the other and can be ported to different versions using plugins. So go for the “Eclipse IDE for C/C++ Developers”. It would have all the functionality needed to set up the toolchain.

Step 2 – Install Eclipse Plugins – Fueling up Eclipse

This step involves adding the necessary plugins to Eclipse which are needed to successfully compile an ARM application.

  • Eclipse CDT
  1. Go to Help > Install New Software.
  2. In the dialog which appears, type “http://download.eclipse.org/tools/cdt/releases/helios&#8221; in the Work With text area.
  3. Press enter.
  4. You will get a window as shown below. Select both the choices and click on Next. Accept the license agreement and continue with the installation.
  5. Once the installation is complete, restart Eclipse.
  • GNU ARM Eclipse Plugin
This plugin is the link between your Eclipse IDE and your CodeSourcery toolchain which we will install in the next step. The plugin works only on Helios as of now. Once the compatibility with Indigo is achieved, the same steps can be followed for setting up the toolchain on it.
  1. Go to Go to Help > Install New Software.
  2. In the dialog which appears, type “http://gnuarmeclipse.sourceforge.net/updates&#8221; in the Work With text area.
  3. Press enter.
  4. You will get a window as shown below. Select all choices and click on Next. Accept the license agreement and continue with the installation.
  5. You will get an unsigned plugin notification during install. Click OK to continue with the installations.
  6. Once the installation is complete, restart Eclipse.

Step 3 – Install CodeSourcery

This step can be put as the most time consuming and mind boggling of the entire process. It took me more than 10 hours to get it working correctly. Thanks to James Snyder I was able to get it up and running in less than 30 minutes.

  1. Ensure again, you have the Apple Developer Tools installed.
  2. Point your browser to Snyder’s github.com project page.
  3. Click on the top right “Downloads” button and download the .tar.gz archive. This is isn’t the toolchain, but a very important makefile written by Snyder that can be used to conveniently build everything from sources, by automating all steps from downloading, compiling and installing the binaries.
The rest of the step is pretty straightforward. Just enter the terminal commands in the exact same order. If, for some reason, the build process fails at any step, restart again by using “make clean”.
  1. mkdir -p $HOME/Work/ – directory for saving all the downloaded content. This won’t contain the installed toolchain. Just it’s .tar archive.
  2. cp $HOME/Downloads/jsnyder-arm-eabi-toolchain-*.tar.gz $HOME/Work/ – copy the downloaded archive.
  3. cd $HOME/Work/
  4. tar xzvf jsnyder-arm-eabi-toolchain-*.tar.gz – extract the downloaded/copied archive.
  5. cd $HOME/Work/jsnyder-arm-eabi-toolchain-*
  6. sudo port install mpfr gmp libmpc texinfo – this will download and build the GMP and MPFR packages. It will take a few minutes for this step to complete.
  7. sudo make install-deps
  8. mkdir -p $HOME/arm-cs-tools/pin – create destination folder for the toolchain.
  9. export PATH=$HOME/arm-cs-tools/bin:$PATH – add the destination folder to the PATH variable. Be sure not to skip this step and step 8, otherwise the procedure will fail.
  10. make clean
  11. sudo CC=clang make cross-binutils cross-gcc cross-g++ cross-newlib – builds the final toolchain. It will take about 30 minutes for complete installation. 
  12. sudo make cross-gdb – builds and installs the debugger.
  13. Close Terminal.
These steps will help you successfully build and install the CodeSourcery toolchain. However, one final step, which is very important, is to set the environment variables to help UNIX know as to where you have installed your toolchain and from where it should pick up the compiler for ARM compilation. This can be achieved by making some changes to .bash_profile script. To do that:
  1. Open Terminal.
  2. Type “open .bash_profile”
  3. In the TextEdit windows which appears, add to the bottom of the text contents – export PATH=$HOME/arm-cs-tools/bin:$PATH
  4. Close the window.
  5. Logout from the Terminal.
  6. Restart Terminal.
  7. Type echo $PATH and in the variables which appear, /Users/<username>/arm-cs-tools/bin should be present.
  8. Another way to ensure you have successfully installed the toolchain and added it to your SYSTEMPATH is to type “arm-none-eabi-gcc –version“. You should get something like this.
arm-none-eabi-gcc (GCC) 4.5.1
Copyright (C) 2010 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

If you are not getting this message, you have missed out some steps above. Delete the folder arm-cs-tools in your HOME folder and repeat Step 3 again.

Step 4 – Firing up Eclipse

Now that the plugins have been installed and the toolchain set up, it is time to write our first ARM code. But before that, one thing to note is that Eclipse doesn’t pick up its PATH variables from the bash directly or rather there is a flaw in Eclipse for Mac. It took me a while to figure this out. So the way out is to edit the proprietary $HOME/.MacOSX/environment.plist file. But an easer way out, is to start Eclipse from the Terminal directly. This way, the PATH we created in our .bash_profile script will be automatically added to Eclipse’s PATH variables. To do that,

  1. Open Terminal.
  2. Go to the directory where Eclipse was installed or its archive unpacked. In my case it was in the Applications folder, so I had to type “cd /Applications”. 
  3. Type “cd eclipse”
  4. Type “open eclipse”

And you will be presented by the ever beautiful, Eclipse IDE. Yes, it is beautiful.

Step 5 – Writing your first ARM Application

  • Open your workspace.
  • Go to File < New < C Project
  • Insert a Project Name. Select “ARM Cross Target Application” and chose “ARM Mac OSX GCC (Sourcery G++ Lite).
  • Click on Finish.
  • Go to File < New < Source File. And name it main.c
  • In main.c, type in a simple program which prints “Hello World”. Need not worry about this program working on your micro-controller. It is just to check if the toolchain is working fine.
#include <stdio.h>
int main()
{
printf(“Hello World”);
return 0;
}
  • Save the project contents.
  • Go to Project < Properties.
  • Click on C/C++build item and set:
    1. Builder Type : External Builder
    2. Check Use defualt build command
    3. Check Generate Makefiles automatically
  • Now click on the small triangle near the C/C++ Build item to view the subitems and then select Settings and set:
    1. Target Processor > Processor : cortex-m3
    2. Additional Tools : Uncheck Create Flash Image
    3. ARM Sourcery Mac OSX GCC C Linker > General. Uncheck all the boxes
  • Click on Apply, and press OK to close the Project Properties window.
  • Go to Project > Build Configurations > Set Active and chose Debug.
  • Go to Project > Build Project. This should compile and build project files for debugging of your project.
  • Go to Project > Build Configurations > Set Active and chose Release.
  • Go to Project > Build Project. Eureka! This should compile your project and build the .hex and .elf files which can be then uploaded to your micro-controller. If build of these files fails, you have not installed the toolchain properly or your PATH variables are incorrect.
Hope this post helps you setup your own ARM toolchain. I took to writing this post because I couldn’t find any which instructs on how to set up an Open Source ARM toolchain on a Mac and specifically on OSX 10.7. It took me a total of 36 hours to get this toolchain working. Why not use KEIL instead? First reason, it is paid and my lab doesn’t allow me to use pirated software. Second, I cannot purchase it. It is $1500 for a single user license. Why pay such a price when you can get all those features for free. All Hail the Open-Source!
Do leave a comment if this post helped you.

Post Navigation