Apr 272008
 

Hi all…

Lately I’ve been busy with university stuff. In particular, my final year project, which is investigating Controller Area Networks, in the context of the Atmel AT91SAM7X256 MCU.  These microcontrollers are a low-cost system-on-chip based around the ARM7TMDI core.  This particular one includes 64KB RAM, 256KB flash, RS-232, device-side USB 2.0, 10/100Mbps ethernet, and of course, a CAN interface.

When I first started looking into this project, I was thinking about using Linux and SocketCAN… well, needless to say the moment I saw the specs on the exact board I was using (the AT91SAM7X-EK), I soon realised Linux was simply out of the question.  That doesn’t mean however, that one is stuck to using proprietary kernels and toolchains.  The following, are some notes on how to code for these things… and where I’m at.

Kernel

You don’t have to use a kernel of course, you can code bare-iron, but I decided to go with a multitasking kernel to make my life easier — I can code each thread to do something basic, and let the kernel manage the IPC and task switching for me, hooking them together.  There are a few options out there, but so far the option I’m liking the most, is the FreeRTOS kernel.  This kernel is free software under the GNU GPL, and supports many platforms, including ARM7.

Toolchain

There are a few compiler toolchains you can use for this board.  The DVD that comes with the board, includes a version of IAR Embedded Workbench, which isn’t too bad, but unless you pay for a license, your code size is limited to 32KB.  The GNU toolchain however, is very mature for the ARM7 platform… and getting a toolchain up and running isn’t too difficult.

FreeRTOS can be built using IAR, and indeed to get me started, that’s what I did.  Once I was comfortable with the system though, I turned my attention to getting a GNU toolchain running on my laptop.  The toolchain needs to be built, targetting the arm-elf platform, using the newlib C library.  Thumb mode, multilib, and interworking support need to be included in this toolchain to build FreeRTOS.  There are numerous prebuilt toolchains, and guides on how to do them from source… but I wound up going my own way…

In my devspace, you’ll find a compressed Makefile.  Download this into an empty directory, decompress it, then rename it to Makefile.  Gentoo users, may find it helpful to symlink their distfiles directory (/usr/portage/distfiles for most people) to ‘src’ — the Makefile uses the same toolchain sources as Gentoo.  Edit Makefile to point to your local Gentoo mirror (I use these mirrors because they’ve got all the sources in one place), then run make.  With luck, it’ll build everything and install it for you.  It runs as a user, then uses sudo to copy the files to /usr/local where they are to be installed.

At the end, you’ll be left with a full arm-elf toolchain, based on GCC 4.2.3, binutils 2.18 and newlib 1.15.0.

Building the FreeRTOS kernel

FreeRTOS comes with numerous demos which can be used as starting points for your own projects.  The best one for the AT91SAM7X using GCC, is the lwIP_Rowley_ARM7 demo.  This demo does three things:

  1. Runs a webserver displaying some task statistics
  2. Flashes the onboard LEDs to indicate it’s working
  3. Emulates a CDC-ACM device, writing characters to it at 115200 baud 8N1.

To start, go into the Demos/lwIP_Rowley_ARM7 directory, and rename ‘makefile’ to ‘Makefile’.  To set the IP configuration, edit EMAC/SAM7_EMAC.h and change the IP address settings as appropriate (line 69 onwards).  Save this, then type make.  It should go ahead and build an rtosdemo.bin file, which is your executable to be flashed.

Flashing the project

This is where my usage of free software came unstuck.  There are a few projects that theoretically allow you to flash these devices.  The kit comes with a SAM-ICE J-Tag, which is equivalent to the J-Link device developed by Segger.  These, to my knowledge, do not work using J-Tag tools available under Linux.  You could use one of the Wiggler-style J-Tag cables, but I don’t have one of those at my disposal.

The AT91SAM7X has a trick up its sleeve though.  If you power the board up for a few seconds with the ERASE jumper enabled, power it down, then power it back up with the ERASE jumper removed, it’ll revert back to using SAM-BA firmware.  SAM-BA allows for the board to be flashed either via the DBGU serial port, or, via a CDC-ACM USB device.  Tools such as Sam_I_Am, then connect to the /dev/ttyACM0 device created.  For this to work, a small patch needs to be applied to the cdc-acm driver in the Linux kernel (This same patch also adds support for the FreeRTOS CDC device created by the above demo).

For me, this has been the most promising, but hasn’t quite gotten things going… I’m able to flash the device, but for some reason, it sees it as an AT91SAM7S256… and the thing won’t boot.  If anyone has some pointers as to what could be going wrong, I’m all ears.

At the moment, I’m using the SAM-BA flashing utility available from Atmel’s website free of charge.  This is a Windows NT utility requiring administrator privileges, which is suboptimal, but so be it, it works, I just boot my desktop PC into Windows 2000, and access the output binary via SMB.  This works, and isn’t too painful.  It may also work in a VM, I haven’t tried yet.

I’ll keep tinkering with the Linux utilities, because I feel it’s almost there… I’ve thrown this post up so that others who may be looking for this information, have somewhere to work from.  Apart from the little issues I’ve had, I’ve found this board quite enjoyable to work with.  I can use mostly my own tools to work with the files, and the C compiler is both stable (unlike the GNU toolchain for Altera Nios II) and fully ANSI C compliant (unlike the Z-World compiler used on Rabbit Semiconductor devices) — a nice change indeed. 😉

  4 Responses to “Open-Source development on the Atmel AT91SAM7X256”

  1. Thanks for the interesting report.
    The reason why SAMBA does not do the trick is that one of the config-bits need to be changed on a SAM7X device.
    Otherwise, your program is in flash, but it is not started (the SAMBA bootloader is started).

    It seems that in your current setup, you have to use your desktop PC with Windows 2000. In this case,
    you could also use the GDBServer which comes with SAM-ICE
    (and is available in the J-Link Software pack, free of charge for SAM-ICE with ATMEL devices. http://www.segger.com/download_jlink.html)

    It would run on the Windows machine (or a VM) and you communicate via TCP/IP (SMB not required).
    A Linux version of the J-Link GDB Server is somewhere in the makes, but does not have high prio.

    More advanced features (optional) of the GDBServer are:
    – Download directly into flash (no need to use an external tool)
    – Unlimited number of breakpoints in flash

    You would need a license for it.
    We do provide free (trial) licenses;
    an inexpensive non-comercial license is available. (http://www.segger.com/jlink_ncu.html)
    If you contact me, I will gladly provide a free license since I would like to get your feedback.

    Best regards,
    Rolf Segger

  2. Hi

    i am currently working on some similar stuff.
    Can you tell me sth. more about the “Kernel Patch” for CDC ? I need to send some Data from a Sam7S256 to Linux – and i can’t! The Board connects to my system like:

    8230.703782] usb 3-1: new full speed USB device using uhci_hcd and address 18
    [ 8230.916402] usb 3-1: configuration #1 chosen from 1 choice

    and lsusb:

    Bus 003 Device 018: ID 03eb:6125 Atmel Corp.

    But that’s it! No way to communicate it seems. Cutecom and so on do not allow anything…
    I would be very happy if you have some idea for me.

    Regards,

    Henning

  3. Well, the patch is linked there right on that post. The link is here: http://dev.gentoo.org/~redhatter/misc/atmel-cdc-usb.diff.bz2

    The patch is compressed using bzip2, and is just applied to the kernel sources by typing:
    $ bzcat atmel-cdc-usb.diff.bz2 | patch -p1

    All it does is add the device ID of Atmel’s SAM-BA firmware to the device driver, so that the ACM CDC driver takes charge.

  4. Greetings,

    Feedback:
    I had to add MAKEINFO=’/usr/bin/makeinfo to the makefile in order for it to work but otherwise it seems to be a nice alternative to crossdev.

    Comment:
    I program my device using SAMBA via Sam_I_Am (http://claymore.engineer.gvsu.edu/~steriana/Software/Sam_I_Am/index.html). Using the ARM-USB-OCD from Olimex I can easily progam the device (without worrying about licensing policies and trials).

    /The Race