Understanding ARM based controller (stellaris) through driverlib or through registers

[Vin255 0]

Hello friends,

         I just now got the stellaris launchpad to have hands on experience with ARM architecture. I have installed the driverlib and I can blink the LEDs through the APIs. The driverlib makes it easy to program the stellaris but with these APIs we cannot understand how the registers are programmed even when we look at the definitions of the APIs. These APIs are specific to a particular family. Thus, I wont be able to understand the ARM architecture. 

        I request you all to please guide me regarding this problem. It would be great if I could find online training material with examples of stellaris, especially without the APIs so that internal complex architecture of ARM (cortex M4F) can be understood.

 

Thanks & Regards

Vin255

[Lyon 3]

Hi,

The ARM architecture is a complex one, so best thing to do is to read the user manual. This is because ARM depart from usual 8 or 16 bit implementations you may know from other brands.

 

Some historical things first: ARM company sell only the project of the core and some peripherals. The buyer then add its own extra peripherals so the final product differ from company to company - so if you need to use a particular brand, first thing first is to read the user manual. For extra readings of the core, you may go to ARM an search their manuals and user documentation.

 

As for API, you must know there are several approaches - one is CMSIS libray, the other one - TI - uses its own driverlib. There are not examples (except blinky program) without driverlib functions, because without it is very difficult to write and then read/understand/remember what you have done.

 

My advise: read the TI docs you may find in Tiva/doc folder, there is one explaining the concept of driverlib and use these and in case of something unclear ask questions about - basically TI uses bit-banding - one macro to write to registers - this has the big advantage to be executed in one clock cycle, so the speed is big, compared to other approaches.

L

[igor 163]

Are you interested in the CPU architecture (ARM, etc. which would apply to most any Cortex M4F)  Or are you interested in understanding the details of the peripherals (TI).

 

If you want the CPU architecture (instruction set, registers, etc.) then driverlib doesn't matter for the most part.  (Basically want information on assembly programming for ARM.)

If you are interested in the particulars of TI's peripherals, then read the TI documentation on the processor, and study the library source code (driverlib and probably CMSIS as well).

(The driver library code gives examples of how to program the peripherals at a low level.)  Of course the particulars of these peripherals only apply to whatever family of

processors TI puts them in, so may not be a lot of point in delving in to that level unless you need to do something that the libraries don't offer.

 

(e.g. the CAN peripheral can do loopback, but the libraries don't provide a way to do that.  So I put together a function that just enabled/disabled the loopback,

but use the libraries for the rest.)

[spirilis 1,265]

I've heard there's an up and coming Open Source library called libopencm3 (formerly libopenstm32?) that aims to become a unified driverlib for multiple Cortex-M families. I think someone here started a port for the LM4F/TM4C series too. @@Rickta59 told me about it on IRC. But one disadvantage is this library won't be in ROM so it will take up flash space and run a tad slower at high speeds (due to flash wait states that don't apply to the onboard ROM) - whether this makes any darned difference remains to be seen IMO. Probably not.

 

So if you have misgivings about driverlib, maybe give that a peek and/or make it better for us

[Vin255 0]

Hi Lyon, Igor and Spirilis

    Thanks for your views. yes, I understand how ARM just licenses the architecture. few questions:

1.

Hi,
The ARM architecture is a complex one, so best thing to do is to read the user manual. This is because ARM depart from usual 8 or 16 bit implementations you may know from other brands.
 

@ Lyon: by user manual you mean the manual of arm cortex m4 from ARM site or the user manual of LM4F230H5QR controller in the launchpad? Or should I read both ?

 

Ok. driverlib is the fastest and efficient to program the particular family. I get it.

 

2. When I checked the dissasembly my prog did not fit in the flash memory since the driverlib funcitons took most of the space in  flash memory. Therefore I have to reprogram every time I disconnect the launchpad. Is there any solution for this?

    I have read that by prefixing ROM_ to APIs we can call the functions from the ROM and save flash memory. I tried it but the function is undefined. I'm missing something here.

 

Thanks!

 

Regards

Vin255

[spirilis 1,265]

Hi Lyon, Igor and Spirilis

    Thanks for your views. yes, I understand how ARM just licenses the architecture. few questions:

1.

@ Lyon: by user manual you mean the manual of arm cortex m4 from ARM site or the user manual of LM4F230H5QR controller in the launchpad? Or should I read both ?

 

Ok. driverlib is the fastest and efficient to program the particular family. I get it.

 

2. When I checked the dissasembly my prog did not fit in the flash memory since the driverlib funcitons took most of the space in  flash memory. Therefore I have to reprogram every time I disconnect the launchpad. Is there any solution for this?

    I have read that by prefixing ROM_ to APIs we can call the functions from the ROM and save flash memory. I tried it but the function is undefined. I'm missing something here.

 

Thanks!

 

Regards

Vin255

 

Be sure to:

 

#define TARGET_IS_BLIZZARD_RB1

(for TM4C123)

or #define TARGET_IS_SNOWFLAKE_RA0

(for TM4C129)

 

before including "driverlib/rom.h"

 

That should do the trick.

 

FYI, if you are using TivaWare 2.1 (latest), you might want to get in the habit of using the new TARGET_IS #define's instead:

 

#define TARGET_IS_TM4C123_RB1

or

#define TARGET_IS_TM4C129_RA1

 

Those #define's, btw, inform the driverlib/rom.h which ROM functions are actually available since they differ from subfamily to subfamily.  (mainly going from TM4C123 to the new TM4C129; the available functions differ slightly, as the clock system has changed)

 

Example (pre-TivaWare 2.1 here, so I'm using #define TARGET_IS_BLIZZARD_RB1)

/* ssi_hello.c
 */

// needed for driverlib rom stuff
#define TARGET_IS_BLIZZARD_RB1 1

#include <stdint.h>
#include <stdbool.h>
#include "inc/tm4c123gh6pm.h"
#include "inc/hw_types.h"
#include "inc/hw_memmap.h"
#include "driverlib/sysctl.h"
#include "driverlib/rom.h"
#include "driverlib/rom_map.h"
#include "driverlib/gpio.h"
#include "driverlib/pin_map.h"
#include "driverlib/ssi.h"

int main()
{
        uint32_t spiword;

        MAP_SysCtlClockSet(SYSCTL_SYSDIV_2_5 | SYSCTL_USE_PLL |
                           SYSCTL_OSC_MAIN | SYSCTL_XTAL_16MHZ);  // 80MHz CPU; speed is calculated as 200MHz/SYSDIV

        MAP_SysCtlPeripheralEnable(SYSCTL_PERIPH_GPIOB);
        MAP_GPIOPinConfigure(GPIO_PB4_SSI2CLK);
        MAP_GPIOPinConfigure(GPIO_PB6_SSI2RX);
        MAP_GPIOPinConfigure(GPIO_PB7_SSI2TX);
        MAP_GPIOPinTypeSSI(GPIO_PORTB_BASE, (GPIO_PIN_4 | GPIO_PIN_6 | GPIO_PIN_7));

        MAP_SysCtlPeripheralEnable(SYSCTL_PERIPH_SSI2);
        MAP_SSIConfigSetExpClk(SSI2_BASE, MAP_SysCtlClockGet(), SSI_FRF_MOTO_MODE_0, SSI_MODE_MASTER, 1000000, 8);
        MAP_SSIEnable(SSI2_BASE);

        spiword = 0xA5;
        MAP_SSIDataPut(SSI2_BASE, spiword);
        MAP_SSIDataGet(SSI2_BASE, &spiword);
        spiword = 0x55;
        MAP_SSIDataPut(SSI2_BASE, spiword);
        MAP_SSIDataGet(SSI2_BASE, &spiword);

        while(1) ;
}

Note if you also #include "driverlib/rom_map.h" you get MAP_ versions of each call, which automatically get replaced with the ROM_ version if it's available or uses a flash-built copy (e.g. "SSIEnable()" rather than "ROM_SSIEnable()") if it's not.  In practice this probably isn't necessary... since all the driverlib stuff is in ROM.

[Vin255 0]

Hi spirilis

    Many thanks for your detail, well informed help. I now understand the ROM_ and MAP_ which I read in lot of posts.It is very clear for me now 

Just 2 more last guidance needed:

1.  I know that we cannot keep on reading the whole user data (manual here of LM4F230H5QR is 1000+ pages) but we should learn how to find the information needed. I also agree that only by programming simple modules we can understand its working. I want to learn the modules slowly one after another. Now I learnt GPIOs, then I want to turn them ON by switches. then by timer. etc.

--> Is this approach good or some other approach is needed?

 

2. I tried to understand the assembly code of my prog in the disassembly. Its complicated . I couldnt find certain instruction from the manual

 for ex;  BCC.N ??main_1   //  this will jump to label main_1 when negative flag is raised. ( .N indicates this)  

but I couldnt find this instruction in the instruction set of manual. 

 

Thank you.

Regards

Vin255

[Lyon 3]

Hi,

To answer your questions: start first with TI's user manual to know peripherals. I should say: " A chapter a day, keeps the forum away" - this is the known fact these days the user manuals are very big, so one chapter each day is better, since you need to read it several times. Every time you can read also the ARM manuals - but these are made as for a " industry standard" they are a little bit harder to swallow.

A second approach is to use the TI's ready made applications - and understand how are made and how the peripherals are used.

Third - since it seems you are pressed to use on-board switches - see this tread, last item: http://e2e.ti.com/support/microcontrollers/tiva_arm/f/908/t/327836.aspx

This is for tutorials for correct use of switches. But I suggest to "switch" to this problem a little bit later, after you run several applications.

For asm instructions - there is a document related to that on TI site - on the TIva processors page / application notes - try to find yourself and if you do not find it, I will come back with the right address. ( this is for learning how to find yourself the needed info. In fact, every application note from there must be read in time of coarse...)

Last - please specify your toolchains to give you the right info (GCC is different from CCS and so on).

[Vin255 0]

Hi Lyon

    thanks for your priceless guidance regarding the manuals! Yes, I'm currently reading them. Ok, I will try to run the application codes to understand the configuration.

    Yes, I need to understand how to find the info and where to find them. This experience will help me in future. 

tool chains: CCS 5.3 with the all the drivers. Even SYSBIOS is available when I open the TI Resource explorer. I will try the RTOS examples much later.

 

Thanking you.

 

Regards

Vin255

 

 

[spirilis 1,265]

Hi,

To answer your questions: start first with TI's user manual to know peripherals. I should say: " A chapter a day, keeps the forum away" - this is the known fact these days the user manuals are very big, so one chapter each day is better, since you need to read it several times. Every time you can read also the ARM manuals - but these are made as for a " industry standard" they are a little bit harder to swallow.

A second approach is to use the TI's ready made applications - and understand how are made and how the peripherals are used.

Third - since it seems you are pressed to use on-board switches - see this tread, last item: http://e2e.ti.com/support/microcontrollers/tiva_arm/f/908/t/327836.aspx

This is for tutorials for correct use of switches. But I suggest to "switch" to this problem a little bit later, after you run several applications.

For asm instructions - there is a document related to that on TI site - on the TIva processors page / application notes - try to find yourself and if you do not find it, I will come back with the right address. ( this is for learning how to find yourself the needed info. In fact, every application note from there must be read in time of coarse...)

Last - please specify your toolchains to give you the right info (GCC is different from CCS and so on).

I am definitely adopting the "A chapter a day, keeps the forum away" plan... Reading the TM4C123GH6PM chapter 2 right now, it's a deep one :-)

[pabigot 355]

I've heard there's an up and coming Open Source library called libopencm3 (formerly libopenstm32?) that aims to become a unified driverlib for multiple Cortex-M families. I think someone here started a port for the LM4F/TM4C series too. @@Rickta59 told me about it on IRC. But one disadvantage is this library won't be in ROM so it will take up flash space and run a tad slower at high speeds (due to flash wait states that don't apply to the onboard ROM) - whether this makes any darned difference remains to be seen IMO. Probably not.

 

So if you have misgivings about driverlib, maybe give that a peek and/or make it better for us

I took a look at libopencm3, which does appear to be active but doesn't seem to have any existing support for Tiva, and only blank headers for Stellaris.

 

Then I looked at TivaWare 2.1.0, which I'm bludgeoning into behaving more like what I want (this concept that every application should have its own startup_gcc.c and linker script is poor toolchain design). While this wasn't hard and I'm busy developing programs and becoming basically familiar with Tiva C, while doing that I notice that both the linker script and the startup_gcc.c file from TivaWare have a software license that explicitly denies the right to use them in "'viral' open-source software".

 

libopencm3 is LGPL, and even though technically LGPL might not be "viral" I doubt anybody's going to pay for a legal opinion on whether it'd be ok to incorporate these fundamental capabilities into another system just to help TI sell chips. The alternative is to throw out TI's startup infrastructure and use the BSD-3-Clause stuff from ARM directly, which is what I would do for my own stuff if I decide to do any open source with Tiva.

[spirilis 1,265]

I took a look at libopencm3, which does appear to be active but doesn't seem to have any existing support for Tiva, and only blank headers for Stellaris.

 

Then I looked at TivaWare 2.1.0, which I'm bludgeoning into behaving more like what I want (this concept that every application should have its own startup_gcc.c and linker script is poor toolchain design). While this wasn't hard and I'm busy developing programs and becoming basically familiar with Tiva C, while doing that I notice that both the linker script and the startup_gcc.c file from TivaWare have a software license that explicitly denies the right to use them in "'viral' open-source software".

 

libopencm3 is LGPL, and even though technically LGPL might not be "viral" I doubt anybody's going to pay for a legal opinion on whether it'd be ok to incorporate these fundamental capabilities into another system just to help TI sell chips. The alternative is to throw out TI's startup infrastructure and use the BSD-3-Clause stuff from ARM directly, which is what I would do for my own stuff if I decide to do any open source with Tiva.

Interesting, I hadn't noticed that in the startup_gcc.c but yep it's there.

 

I checked Energia's core, which evidently has a startup_gcc.c without that clause.  Its contents look similar for all intents and purposes too.

Their linker scripts look doctored up, probably based on the original TivaWare examples but sufficiently re-worked.  No copyright/license notice on that one.

[spirilis 1,265]

I took a look at libopencm3, which does appear to be active but doesn't seem to have any existing support for Tiva, and only blank headers for Stellaris.

 

Then I looked at TivaWare 2.1.0, which I'm bludgeoning into behaving more like what I want (this concept that every application should have its own startup_gcc.c and linker script is poor toolchain design). While this wasn't hard and I'm busy developing programs and becoming basically familiar with Tiva C, while doing that I notice that both the linker script and the startup_gcc.c file from TivaWare have a software license that explicitly denies the right to use them in "'viral' open-source software".

 

libopencm3 is LGPL, and even though technically LGPL might not be "viral" I doubt anybody's going to pay for a legal opinion on whether it'd be ok to incorporate these fundamental capabilities into another system just to help TI sell chips. The alternative is to throw out TI's startup infrastructure and use the BSD-3-Clause stuff from ARM directly, which is what I would do for my own stuff if I decide to do any open source with Tiva.

Ok so in "examples/project/startup_gcc.c" that clause isn't there, but in any of the specific board+boosterpack examples it is.

 

examples/project/startup_gcc.c preamble:

//*****************************************************************************
//
// startup_gcc.c - Startup code for use with GNU tools.
//
// Copyright (c) 2013-2014 Texas Instruments Incorporated.  All rights reserved.
// Software License Agreement
// 
//   Redistribution and use in source and binary forms, with or without
//   modification, are permitted provided that the following conditions
//   are met:
// 
//   Redistributions of source code must retain the above copyright
//   notice, this list of conditions and the following disclaimer.
// 
//   Redistributions in binary form must reproduce the above copyright
//   notice, this list of conditions and the following disclaimer in the
//   documentation and/or other materials provided with the  
//   distribution.
// 
//   Neither the name of Texas Instruments Incorporated nor the names of
//   its contributors may be used to endorse or promote products derived
//   from this software without specific prior written permission.
// 
// THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
// "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
// LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
// A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
// OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
// SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
// LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
// DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
// THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
// (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
// OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
// 
// This is part of revision 2.1.0.12573 of the Tiva Firmware Development Package.
//
//*****************************************************************************

Most likely just really sloppy work on the part of the folks putting TivaWare together, or braindead policies for how to present the licensing.  For my own work I'm just taking my copies of startup_gcc.c and replacing the preamble with the permissive version since the files are otherwise identical.

[pabigot 355]

Most likely just really sloppy work on the part of the folks putting TivaWare together, or braindead policies for how to present the licensing.

Agreed on the later. For the former, I think Energia really needs to take a look at what they've done, unless TI has indemnified Energia against IP claims.

 

You're braver than I am; I won't even quote your workaround let alone use it myself. I'll be doing a clean startup infrastructure from the ARM CMSIS GCC files instead, BSD-3-Clause licensed and attributed.

[Rickta59 589]

I took a look at libopencm3, which does appear to be active but doesn't seem to have any existing support for Tiva, and only blank headers for Stellaris.

There is a wiki with status. Although, it seems to somewhat out of date. I'm successfully using libopencm3 with an stm32f051 chip and it works great. The stm32f0 cortex-m0 isn't even mentioned in the status here:  http://libopencm3.org/wiki/Status

 

There is enough peripheral support in libopencm3 to build the Blackmagic Probe software and load it on your TI stellaris or tiva lp board. That is what I do with my TI lm4f boards. Find the stellaris BMP code here: https://github.com/xpgdk/blackmagic/tree/stellaris_launchpad/src/platforms/stellaris-launchpad