Author Topic: First steps with the LM3S6965  (Read 13953 times)

Offline mark

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 3237
    • View Profile
    • uTasker
First steps with the LM3S6965
« on: November 10, 2007, 05:34:46 PM »
Hi All

It is always exciting when you start a new project. It gives you a chance to forget the previous ones which sometimes developed into a tangled mess which you may prefer to forget. This next one will be perfect - a fresh start, a clean sheet...

Well we know what usually happens. The original euphory gets dampened by the harsh realities of the real work - pressure, deadlines to meet, software which 'should' work fine has some niggling bugs which can only be solved by all-night sessions. Is it a problem with the chip? perhaps with the compiler?...minutes, hours, days later... ooops, ehrr, that was a stupid mistake which I won't make again...

The Luminary Micro device LM3S6965 is one of these chances since it uses the new CortexTM M3 core and it promises to be an exciting new chip from a new company which is churning out new derivitives as fast as they can update their web site to cover them.

The chip is new to me but I spend my first short debugging session on the path to getting to know and love (or hate..?) the new family of chips which promise to open up new possibilities of embedded Ethernet capability. Support for the uTasker will only be possible after the normal learning curve but here's a taste of how it is going:

Getting Started with the LM3S6XXX

The following describes the process of getting to know and use the Luminary Micro Stellaris LM3S6965. For the exercise I bought an LM3S6965 evaluation kit and downloaded the Kick Start evaluation version of the IAR compiler Version 4.42A which includes support for the CortexTM-M3 processor and has various example of software controlling various peripherals.

In fact I bought an evaluation kit including KEIL software on the CD but decided against Keil due to the fact that the evaluation version limits the code size to 16k. The IAR kick start version has a 32k limit which is realistic to show demo software with a decent mix of features as necessary when working with protocols such as TCP/IP. Experience has shown that with 16k (even in Thumb mode on an ARM7) the 16k limit is just too restrictive to let anyone really experiment with useful embedded IP stuff. The CortexTM-M3 doesn’t have, or need, a thumb mode but code sizes equivalent to ARM7 thumb can be expected (although higher performance can be assumed).

The board in the LM3S6965 evaluation kit has a USB JTAG debugger built in to it so there is no need to use an external one. The debugger is based on the well known FTDI chip which communicates as virtual COM port. It is not the fastest method of downloading and debugging but was used to get to know the board and verify its usability.
[In addition to the LM3S6965 evaluation kit I also have two others which may be useful for comparisons. I have an LM3S1968 from the 1000 series with no Ethernet interface and an LM3S8962 with an additional CAN interface. The LP3S8962 kit comes with an LM3S2110, which doesn’t have Ethernet but does support CAN, for testing together with the LM3S8962].

Installing the IAR kick start version and the FTDI driver

You can order the evaluation board with IAR kick start software or else simply download the newest version from the IAR web site. You will need to register and then you will receive an activation key.

The software includes drivers for the FTDI chip so best get these installed as first. I installed them before installing EWARM (Embedded Workbench for ARM) by connecting the USB cable from the LM3S6965 evaluation board to a free USB port and pointing Windows to the IAR program directory (\arm\drivers\FTDI) so that it could find the driver. There is an installation guide there too which suggests getting latest drivers from the FTDI web site, which I tried following, but Windows didn’t want to be able to understand the new drivers so I simply stuck with the ones delivered with the Kick Start software. Note that there are in fact 2 or 3 different drivers required so don’t get upset when you keep getting asked to install again each time you think that it has already finished. Just keep pointing to the same driver directory and it should complete. I kept getting the message that the device was not working correctly but could still see a new COM port in the device manager (open system control, then system/hardware and then device manager and expand the COM port group) called “Stellaris Virtual COM port" – COM4 in my case on my WinXP PC).

I opened a workspace example in the IAR program directory (\arm\examples\Luminary\LM3SXXX\dk-lm3Sxxx.eww) and compiled the gpio_led demo project. This compiled with no errors and afterwards I could download the code to FLASH (the set up in the project is for FLASH download) by pressing on the debug button.

As I said previously, it is not the fastest debugger and stepping through code requires a little patience but it does work otherwise fine, so there was nothing to stop me getting down to doing some real work.

Start up code

Any one familiar with working with ARM7 or ARM 9 etc. may be a little surprised that if you remove the debugger setting “Run to main” – which is useful to see what is happening on start up – it doesn’t actually make any difference: the first executed code is the first line of main!

I was at a Luminary CortexTM-M3 seminar a while back and this was one of the things that was repeatedly stated as being a big plus. “No assembly code required—ever!”. The majority of discussions in the seminar still worked with assembler code… but let’s take a look at what the big deal is here.

The first thing to remember is that the CortexTM-M3 processor is a new version of the ARM processor and it has a number of changes. The original ARM architecture has been very successful but does have a few basic problems or weaknesses which have been improved on, with the result that the Cortex™-M3 is easier to use, faster and uses less code space to achieve higher performance. Major improvements have been achieved by adding a vectored interrupt controller with guarantied interrupt latency (faster than any previous ARM) which also supports up to 240 prioritised interrupts and nesting. This means that the chip manufacturers no longer have to bolt on their own interrupt controller since it is included in the core – this will probably make it easier to move between CortexTM-M3 processor types since the interrupt controller is now also standardised.

The CortexTM-M3 has a different vector table (as well as different internal registers) – remember this is not an ARM as you may already be used to. The vector table looks like a Motorola (Freescale) vector table, with the first long word being the value which is loaded to the stack pointer and the second long word being the start address. As long as the code can ensure that the pointer to the top of stack can be forced to reside at address 0x00000000 and a pointer to the routine main is forced to reside at address 0x00000008 then the routine main() is the first instruction which will be executed. Since the CortexTM-M3 supports what is known as the Thumb-2 instruction set, which never needs to swap between Thumb and ARM, nothing else is required to start working.

I don’t exactly see the difference to the architecture that Motorola has been using since the beginning of time and I assume that if Freescale marketing had been clever, it could also have pointed out that theoretically it never needs any assembler code to operate...we will see whether there are other big differences as work progresses!!

The first demo code which runs doesn’t use any interrupts (as is typical of demo code) and I realise that it doesn’t actually do anything visible on the board which I am using but the debugger operates correctly and it illustrates setting up the PLL and configuring some ports so it may prove a useful reference if things don’t start as expected in the main project.

To be continued...

Comments welcome, as normal.