Support: TrueSTUDIO Pro is sold in North America with 12-months of technical support included in the price. When is it good to have tech support?
Eclipse Help: TrueSTUDIO is based on the Eclipse framework. From time-to-time customers require assistance in resolving Eclipse issues. Atollic has several Eclipse experts who monitor developments, and who are capable of suggesting effective work- arounds to keep your development going during the time when Eclipse bugs are being fixed.
Updates: Support also means you get updates to the tools that support new devices with project startup wizards, linker command files, flash programming utilities and have compiler bug fixes and enhancements. The debugger is another area where updates confer value as the capabilities in this area are constantly evolving.
Time to Market: Most customers do not attempt to complete important projects with unsupported tools, because maintaining their own tools takes time away from their real mission of developing their product and making it better than those of the competitors.

Superior Debug Capability: TrueSTUDIO Pro debugging capabilities are considerably superior to those of the evaluation version Lite tools.
JTAG Probe Flexibility: TrueSTUDIO Pro version supports a number of popular  JTAG probes including Segger J-Link. Segger J-Link is mentioned particularly because many companies choose this tool for reasons other than the fact that it is a state-of-the-art, cost effective JTAG debug solution. The value add in Segger J-Link comes when companies are interested in doing low volume production runs prior to turning production over to another party. Those wanting this capability can buy software that turns J-Link into a production programmer. No other JTAG debug probe on the market has this option to do double duty as a debugger and a production programmer. Other JTAG probes confer their own special capabilities as well, and give the developers choice in this diverse market.
Special Function Register Displays: TrueSTUDIO Pro has an SFR viewer. The SFR viewer shows you detailed information on the special function registers of the part, including value, address, individual bits. Changing bits from the SFR window is easy. This is indispensable, as the SFRs are where the real work of an embedded applicaton is done, and where the core meets the outside world. Without easy access to this memory space, development and debugging become needlessly tedious and time consuming.

The SFR Viewer allows you to efficiently set bits in the registers and register sub fields. Just click on the subfield name and go to the corresponding bit and make changes by clicking on individual bits. Notice that below the bit field, useful information about register is displayed including the sub-field name, and register properties.

In this case, a bus fault error occured during execution of the application code. Using the Special Function Register Viewer, the user quickly identifies the particular sub-field of the register so that precise information can be obtained about the nature of the fault.  

GUI Support: TrueSTUDIO Pro implements many more GUI controls that the Lite version. The Lite version gives you minimal ability to configure and control your application via the GUI. You have to resort to knowing gcc compiler and linker switches to accomplish a lot of common tasks. The superior GUI in Pro version makes control easy, fast and positive and helps you set up projects faster, configure them better, and take advantage of your options better.

PC Compiler: TrueSTUDIO Pro version includes x86 compiler and linker. Why is this important? Many embedded developers go out and buy VisualC++ or some other tool for tasks like algorithm development that they prefer to do in the more familiar environment of a PC. Further, a lot of engineers use PC compilers to create test harnesses that are interfaced to the embedded target via serial or parallel ports or Ethernet/TCP/IP. With the Pro version’s multi-target debugging capability, you could for example start the PC session in one instance of the debugger and step through PC code that exercises the target. In another instance of the debugger, you could see how the target reacts to signals and test conditions presented by the test harness.

Code Review Tools: TrueSTUDIO Pro has tools for initiating, implementing and managing Code Review sessions by teams of developers. Integration with revision control repositories means that TrueSTUDIO developers can collaborate on code review sessions  whether they are together in the same office or different sites across the world. Respected embedded systems developer, author and lecturer Jack Ganssle argues cogently at: http://www.ganssle.com/inspections.pdf that the cheapest way to avoid software bugs is to not put them there in the first place, and that the best way to make that happen is to conduct code reviews that involve the development team and other project stakeholders.

Revision Control Clients: TrueSTUDIO Pro has a client for revision control database servers such as Subversion and CVS. Revision control is an absolutely indispensable element of the professional software development process. Serious organizations cannot neglect this aspect of the development process without serious risk to product quality and possible legal exposure. It is not a question of whether or not you incorporate this into the software build process, it is how. TrueSTUDIO Pro makes it considerably easier to do this essential task by incorporating the client into the IDE. You do not have to change the way you work if you are using an existing Revision Control scheme, TrueSTUDIO just makes it easier because you no longer have to shell out of the IDE to accomplish these tasks.

Bug Tracking Clients: TrueSTUDIO Pro has a client for bug tracking database servers. You can use any one of a number of popular and open source bug tracking database servers such as Bugzilla, TRAC etc. Again, you do not have to change the way you work, TrueSTUDIO Pro just makes it easier, faster and more convenient. Not only can you manage bug reports, but you can manage your list of ideas for future revisions and enhancements using the same mechanisms. 

TrueANALYZER Evaluation: TrueSTUDIO Pro has a one week evaluation period of Atollic TrueANALYZER. TrueANALYZER is a high level code analysis tool that is capable of MC/DC coverage of code. TrueANALYZER is used by serious software developers who must adhere to rigorous code testing standards to ensure quality, reliability and availability of their applications. 

Lots of Nice Features: TrueSTUDIO Pro has a NotePad, Programmer’s Calculator, Instant Search, Full Screen Option, Regular Expression Coloring in the build log among a host of other useful features that help developers increase productivity on the way to a smoother development experience.

There are a number of other reasons that developers may wish to consider upgrading to TrueSTUDIO Pro. These are found in conveniently tabulated form at: http://atollic.com/download/Atollic_TrueSTUDIO_Feature_comparison.pdf

Please call or email if you wish to discuss upgrading to TrueSTUDIO Pro.

Mark

Mark Moran
Senior FAE
Joral Technologies
www.joraltechnologies.com
mark.moran@joral.ca
Voice: 1-877-465-6725
Fax: 1-866-735-1813
Skype Account: markm94133

Years ago, when I had more money and free time than I do nowadays, I used to enjoy jumping out of airplanes for fun. The only non-fun part was enduring the endless stream of rhetorical questions about “jumping out of a perfectly good airplane” from those uninitiated to the joys of this activity. Trust me; some of those old crates that jump zone owners used to haul our butts up to altitude were far from perfect… But I digress. 

Anyway, one fine summer afternoon in Northhampton Massachusetts, I was donning my parachute when I happened to glance over at the active runway. There, I saw a twin engine Beechcraft Bonanza coming in for a landing. He was way too close to the ground to have his wheels still up. Seconds later, I was treated to the unusual sight of an aircraft being reunited with earth by its belly rather than its wheels. Ironically, it would be the second time within a year that I would witness this uncommon event. 

Aviators have a saying about their brethren who land with their wheels up: “There are two kinds of pilots – those who have and those who will.” So, what do embedded systems programmers have in common aviators? The answer is that at one time or other, both will violate the simplest, most elementary and cardinal rule of their trade. For flyers, it is making sure to lower the wheels prior to landing. For embedded C programmers, it is remembering to use the volatile keyword when and where appropriate. 

It is not possible to overstate the importance of the volatile keyword in embedded systems programming. When teaching C programming, volatile gets the short shrift from most instructors. Programming courses typically focus on procedural programs, the kind that have a start and an end (at least in principle if not in practice). In these cases, programmers can write successful programs for years without ever needing to use the volatile qualifier. In event driven programming paradigms that dominate embedded systems, you are headed for big trouble if you do not understand the proper use of volatile. 

So, what does the volatile keyword do for you? When you declare a variable, volatile tells the compiler that the value of the variable may change at any time-without any action being taken by the code the compiler finds nearby. Using volatile will tell the compiler always to read the value of the variable whenever it is used, say in a test, even if the code in the module in which the variable being used does not change it. When compiler  optimization is completely turned off, most compilers make no attempt to eliminate potentially redundant read/writes of memory locations. Therefore, omitting the volatile keyword in a declaration probably will not hurt you in this case.

OK, now crank up the optimization one notch, and the compiler says to itself, “let me look for situations where this variable has not been written to lately. If it hasn’t, I don’t have to read it again, I can just use an old or cached value.” That might be OK in a procedural program where changes to a variable value usually happen locally. The volatile keyword is important in an event drive program employing a foreground/background strategy because the compiler may not realize that a variable used in the foreground was unexpectedly modified by a background process. So the compiler’s assumption “I can just use the old value” is no longer valid. The volatile keyword is like saying to the compiler “hey buddy, not so fast, read that variable’s value anyway even if you think the read is redundant.” This ensures that tests of that variable’s value in a foreground process come out right, reflecting any updates made to that value by the background process. 

To make matters worse, omitting volatile where appropriate almost never hurts you when you are building your code using the “No Optimization” level of your compiler. Once you start using optimization, mysterious behavior happens that you did not see before. Debugging problems resulting from not using volatile will drive you crazy because the code appears to be correct.  Different compilers do different things, so there is no hard fast rule to predict what kinds of problems will occur. Sometimes you see code jumping to incorrect locations, or applications may just stop executing entirely. Since these problems occur at higher optimization levels it is hard to set meaningful breakpoints with a debugger. You begin to wonder about things like device driver headers, hardware dependencies, compiler bugs and all sorts of other stuff that distracts your attention from the real problem. Solving these kinds of problems often requires you to read and understand the assembly language that the compiler produces, usually the developer’s avenue of last resort.

Here is your first takeaway: Scrutinize your code for any variables used between modules and between processes. They are probably good candidates for being declared with the volatile keyword. 

Here is your second takeaway: Even if you think you know about volatile, read up on what the experts have to say and review some illustrative examples. The use of the volatile keyword has been described and shown in examples far more eloquently than I can do so. Here are some resources: 

“Introduction to the Volatile Keyword,” Nigel Jones – originally published in 2001, this Golden Oldie is the best works on the subject, and has been frequently cited over the years. See it at: http://www.eetimes.com/discussion/other/4023801/Introduction-to-the-Volatile-Keyword or http://www.netrino.com/node/80 

Nigel also writes at www.embeddedgurus.com/stack-overflow these days.

By the way, if you are new, semi-new, moderately experienced, or an open minded veteran in embedded systems programming, it is worth your while to read whatever Nigel Jones has to say on embedded C development. His advice is pertinent, sound, and should be taken to heart by everyone writing embedded applications in C. Another good guy to know about is Dan Saks. Dan writes more on the C++ side of things, but his stuff should be carefully reviewed by embedded C programmers as well. Rounding out the trio of amigos of wise embedded developers is Jack Ganssle. His Break Points column that you see at: http://www.eetimes.com/design/embedded should be read by embedded developers the way devout Christians read the Bible. If three wise men are good, why not go for four? Look in on Michael Barr’s site at http://www.netrino.com/ for loads of good embedded programming tips and tricks of the trade.

More Resources: Other words of wisdom on the use of volatile and other equally important C constructs that especially apply to embedded systems work can be found at: http://www.netrino.com/node/241 

Wikipedia, as usual chimes in with some excellent advice, this time at: http://en.wikipedia.org/wiki/Volatile_variable 

A broader discussion that includes some excellent comments on volatile is at wikibooks: http://en.wikibooks.org/wiki/Embedded_Systems/C_Programming 

This article at safercode.com dives in a bit further and explores when volatile may not be appropriate as well: http://www.safercode.com/blog/2009/02/24/volatile-c-keyword-myths-dispelled.html 

If you are using C++ in embedded systems, Dr. Dobbs Journal has some good thoughts at: http://www.drdobbs.com/184403766;jsessionid=R5KIPGEPCGDZHQE1GHPSKH4ATMY32JVN

Every embedded developer’s browser should have a bookmark for a web site called stackoverflow.com. They have a nice little example of programming problems solved at: http://stackoverflow.com/questions/72552/c-when-has-the-volatile-keyword-ever-helped-you 

So there you have it, an amusing little story from real life, a salient analogy between two apparently disparate professions, an introduction into why the volatile keyword is important in C embedded systems applications, and some great resources for further reading. Enjoy!

Send your comments, questions, complaints to me at: 

Mark Moran
Senior FAE
Joral Technologies
www.joraltechnologies.com
mark.moran@joral.ca
Voice: 1-877-465-6725
Fax: 1-866-735-1813
Skype Account: markm94133

Question: I have built a project using the Wizard, and when I click on the launch debug icon, I see a pop up window saying:

Unable to Launch 

      The selection cannot be launched, there are no recent launches 

Answer: This is a by product of the ability of Eclipse to keep more than one debug configuration for a given project. When you launch, Eclipse resolves the debug session that it thinks appropriate. To do this it looks for clues like, but not limited to, which projects are open, which project is in focus, which file is in focus etc. I observed this error once after building a fresh project using the Wizard, and pausing to investigate the warnings produced by the compiler. In doing so, I inadvertently left the ‘Problems’ window in focus. This inhibited Eclipse’s ability to resolve the correct debug configuration. Clicking on the project name in the Project Explorer window usually solves this. 

Question: When launching the debugger, it appears to program the part, but the debugger comes up running instead of stopped at the first line of main.c, and the code window is blank.

Answer: Check to see that your build matches the way the BOOT pins on your board are configured. Pay particular attention to the state of BOOT0. According to the ST documentation, this must be grounded for Flash operation. On the ST 3210x evaluation boards, Switchs SW1 and SW2 must be set appropriately. See your documentation. Below is a portion of the schematic for the STM3210C showing how ST configures BOOT0.

Further discussion: In the figure taken from TrueSTUDIO/STM32, the code was built by TrueSTUDIO for Flash, and programmed into flash. You can see that in the Console window by viewing the load reports which show various segments going into Flash starting at address 0×80000000, which is Flash for the Cortex M3 part. In this case, the target STM3210C was set to execute code from RAM. Note that there is a cryptic error message saying 0×2000001e2 in ?? (). Also there is a message where the code should be saying that <Symbol is not available> 0×20000004. These are hints that execution is kicking off expecting to find code in RAM, but in fact, the code is in Flash. You can verify this with the ST-Link utility by selecting View\Device Memory from the main menu option. You will see the stack pointer with a value of something like 0×00000120 at address 0×08000000, followed by the address of the reset vector, which is something like 0×080015B9 in the next word.

If you do not have the ST-Link utility, get it here:

http://www.st.com/mcu/familiesdocs-110.html

Scroll to the bottom of the page.

Question: Sometimes when I am going through the edit/build/debug/rebuild cycle, I see a message pop up about being unable to clear a breakpoint when I launch the debug configuration. 

Answer: This issue is unresolved and under investigation at this point. It may be an Eclipse but, or it may be a problem with gdbserver. However, a workaround is to use ST-Link to erase the chip, and then restart TrueSTUDIO. This will resolve the problem. 

Question:  When in an interrupt service routine, I try to put the cursor on a line of code and run to that line by pressing CTRL-R. I see a message like:

Pressing CTRL-R again causes gdbserver to halt.

Answer: As of TrueSTUDIO(R)/STM32 ver 1.4.0, this is a bug in gdbserver. There is a beta available that fixes this problem. Email mark.moran@joral.ca for the beta version of gdbserver and instructions how to install.

Got a question or comment? Sent bouquets and brickbats to: 

Mark Moran
Senior FAE
Joral Technologies
www.joraltechnologies.com
mark.moran@joral.ca
Voice: 1-877-465-6725
Fax: 1-866-735-1813
Skype Account: markm94133

Downloaders of Atollic TrueSTUDIO Lite evaluation version will no doubt be keen to explore these code examples as part of their effort to evaluate the suitability of both the microcontroller and the library for use in their projects. This article gives developers new to TrueSTUDIO a step-by-step tutorial on getting these projects up and running with TrueSTUDIO.

This article assumes that the user has a basic working knowledge of Workspaces, Projects, the Build Environment and launching a Debug Session. It also expects that the user has exercised the TrueSTUDIO project Wizard at least once to create the basic project template and put the code into memory using an ST-Link JTAG probe. For a quick overview of these topics, the user if referred to the QuickSTART document on the Atollic site at: http://www.atollic.com/download/Atollic_TrueSTUDIO_STM32_QuickstartGuide.pdf

So, let’s build a project! This example shows how to build the SysTick example  which is found in the ST Standard Peripheral Library in the folder path: STM32F10x_StdPeriph_Lib_V3.3.0\Project\STM32F10x_StdPeriph_Examples\SysTick.

This example blinks the LEDs on an ST evaluation board at different rates using a delay that works off of the interrupt handler for the SysTick interrupt. It is easy to understand, and works “out of the box.” I am using the STM3210C board in this example, but the procedure is basically the same for the ‘B’ and ‘E’ boards as well.

The first step is to generate an STM32 project for the STM3210C board using the Wizard. Start by selecting the appropriate Workspace by either switching to it, or accepting the default Workspace at startup. The select File->New->C-Project from the Menu bar in TrueSTUDIO. Fill in the first dialogue box that pops up with your project name, and select STM32C Project under the ‘Executable’ category. Click ‘Next.’

Fill out ensuing dialogue box with the board you are using. I have an STM3210C, so I check that one. Doing this greys out the microcontroller family and microcontroller pull down lists . Then I select RAM. You could leave the default memory as FLASH, but I use RAM to save on my flash write/erase cycles and because I like to leave my board jumpers in the RAM position as much as possible. As we will see, you must add a line of code to main.c later on to tell the application that you want to look for the interrupt vector table in RAM. Finally, your board must be jumpered to execute code from RAM. This is described in the ST STM3210x documentation On the STM3210C board, that means SW1 and SW2 are switched to the ‘1′ position, which is to the right.

Finally the Wizard wants to know what debug probe you want to use. Lite users are limited to the ST-Link probe, but Pro users can use a variety of JTAG dongles. You can safely accept the default Debug and Release versions of the configurations on the last dialogue box.

Once you exit the dialogue boxes, the Project Explorer window will be populated with your project structure, and it will build the project automatically. (This is a configuration option in the Build environment. If you don’t like automatic builds, you can highlight the project, right click and select ‘Properties’ and change the configuration in the C/C++ Build dialogue box). You will see a successful build. If you click on the ‘Problems’ tab, you will see warnings related to minor coding problems that can safely be ignored for the purpose of this exercise. What you have built so far is the default project produced by the Project Wizard in TrueSTUDIO. It is basically a main() with some board configuration and a simple while loop that has a counter and calls an LED toggling routine. This project is not our final goal. We will now adapt this project by substituting the appropriate modules from the SysTick example.

Now, what you need to do is to delete the following files from the src directory in your project:

main.c

stm3210x_it.c

stm3210x_it.h

There are two different ways to incorporate the appropriate replacements into your project, copying them into the src folder of your local project directory so as to create local copies or linking to the files in the ST Standard Peripheral Library distribution. For this exercise, I will create local copies. Because I chose RAM memory for execution in my project configuration previously, this will necessitate adding a line of code to the main.c file. If I were to link to the main.c in STM32F10x_StdPeriph_Lib_V3.3.0\Project\STM32F10x_StdPeriph_Examples\SysTick, then I would be modifying that copy. This is probably not a good idea, as I would like to leave that copy “pristine” for future reference and usage.

Navigate to the code in folder ..\ STM32F10x_StdPeriph_Lib_V3.3.0\Project\STM32F10x_StdPeriph_Examples\SysTick and copy main.c, stm3210x_it.c, and stm3210x_it.h into the src folder of your local project folder. In this case, the example project has a main.h file for main.c, so you must copy that over as well. Once you do that, the Project Explorer window will  be repopulated with the new files.

Finally, add the following line of code in your main.c file to tell the microcontroller to look for the interrupt vector table in RAM:  NVIC_SetVectorTable(NVIC_VectTab_RAM,0×0);

Save your copy of main.c and clean the project by selecting Project->Clean. Clean deletes all of the old object files and rebuilds the project from scratch. This is probably overkill, but I like to select this option instead of a simple rebuild, just to be sure that every module is freshly build and that old copies of object files are gone.

Now, you are almost ready to go. At this point, make sure that your project name is highlighted in the Project Explorer. You are about to launch a Debug Session in order to program the part and kick off a debug session where you can step, run to breakpoint, examine registers and memory or just run the application. If you had highlighted say, the ‘Problems’ tab down by the Console window of the IDE, you would not be able to resolve the correct Debug Session. You would get a very confusing error message about not being able to launch the Debug Session because there were no previous launches. This situation arises because Eclipse is capable of storing several different Debug Sessions that you can define and use as the situation dictates. Different Debug Sessions may use different debug probes; have custom startup scripts or whatever configurations you deem convenient and necessary. Eclipse needs to resolve the appropriate choice, and it does this from the Project properties. It cannot do this if the ‘Problems’ tab is in focus. This is one of the many delightful peculiarities of the very powerful Eclipse IDE.

You launch the Debug Session with the debug icon that is  under the ‘Manuals’ entry in the Menu bar. It looks like a, you guessed it… bug! If you were to click on the little triangle to the right of the bug, you would get a list of previously defined Debug Sessions to choose among. There should only be one at this point in your project creation.

What you should see when you launch the Debug Session for the first time is the Debug Session dialogue box where you can review and confirm or change settings as you desire. The settings should reflect the choices you made in the Project creation Wizard, but if not, change them to agree with your Wizard selections. Click on the ‘Apply’ and then ‘Debug’ buttons. You should see the code programmed into the part and a break at the first line of main.c. You are now ready to step over, step into, run to cursor or breakpoint, examine memory and registers or just run your code. You should see the 4 LEDs under the LCD display blinking at different rates when you run.

Your comments, questions and feedback  on this article are welcome. Call or email me.

Download already built projects here.

Mark

Mark Moran
Senior FAE
Joral Technologies
1-87-465-6725
www.joral.ca
Skype Account markm94133

For the first time in development tools history, developers can directly see within an IDE power consumption measurements along side the display of code execution. This capability is unprecedented and demonstrates a real commitment on the part of IAR to giving developers crucially important views into applications where it is needed the most. Using these data, developers can focus on the code in parts of applications that draw the most current. Only a few percent reduction in power usage can mean months or years of extra battery life of a field deployed product.

You can see a short, informative clip on power debugging at: http://www.youtube.com/watch?v=vrMpD3ttgCE

What more could a developer ask for? How about the ability to generate position independent code? This is another very nice feature that modern developers can use to cope with the demands of increasingly complex applications.

All in all EWARM 5.50 is not just a tweaked versions of an already great product. It raises the bar significantly with tools that should be part of every developer’s repertoire.

Check it out.

Also, keep an eye on their video tutorials page at: http://www.atollic.com/index.php/videotutorials - there will be a new video on the topic of code coverage posted on Tuesday, 23 March 2010.

• TrueSTUDIO® Lite, the FREE no-code size, no time-limit evaluation version of TrueSTUDIO®-Pro C/C++ development tools.
• ST Microelectronics evaluation board
• ST Microelectronics ST-LINK debugger
• STM32 documentation and code examples 

Here is where to get all that cool stuff: 

TrueSTUDIO® Lite – Go to the Atollic web site at http://atollic.com/index.php/download  you will find the download button for the Lite version “Free Download Lite Version.” Be sure to also click on the second orange button from the top where you get the TrueSTUDIO® Quick Start Guide. You want to follow this religiously when you create and debug your first project. 

STM32 evaluation boards from ST Microelectronics are the best. They are completely kitted out with all peripherals and ports to the outside world that you need to really get to know the part. The new ST-LINK JTAG debugger is an inexpensive and reliable way to download code and do run control debugging. Find them to buy here: http://www.st.com/mcu/modules.php?name=mcu&file=debug_tools&fam=110

Once you get your feet wet with TrueSTUDIO®, you can head over to the page at: http://atollic.com/index.php/videotutorials. Here you can see in-depth video tutorials about various phases of tools usage. They are excellent. As of March 16^th they have videos on creating and building projects and the Eclipse editor. The debugging tutorial is due out soon. 

Users of TrueSTUDIO®-Pro can learn about the seamless integration of advanced tools from the Code Review, Bug Tracking and Revision Control videos. UML Modelling and Code Coverage Analysis (TrueANALYZER) are coming soon! TrueSTUDIO®-Pro is a cost-effective, professional, highly integrated C/C++ toolchain that enables single users or teams of developers to benefit from features of advanced development tools to produce higher quality software in a shorter period of time.

Then, you want to head over to: http://www.st.com/mcu/modules.php?name=mcu&file=familiesdocs&fam=110&doc=60
Here you will find document document RM0008 (informative name, eh?) which the reference manual for the STM32F101xx,  STM32F102xx, STM32F103xx, STM32F105xx, and STM32F107xx families.

Now go  to:  http://www.st.com/mcu/modules.php?name=mcu&file=familiesdocs&fam=110&doc=76 and download STM32F10x_StdPeriph_Lib, which is the second entry from the top. This is the latest version of the standard peripheral library firmware that ST provides. When you unzip it, you will see that it has loads of examples of how to do the things you want to do.

TrueSTUDIO® has a project wizard that creates a project for the ST eval boards. This brings in all of the peripheral library code, and gives you a skeleton of an application that initialized the LCD, the LEDs and a while(1) loop. You can then take the examples from the aforementioned STM32F10x_StdPeriph_Lib and cut them into this basic application very quickly in order to try things out. Recommend you go slow at first. Do one peripheral at a time and get it working to your satisfaction before moving on to the next.

Another very good reference is the book by Joseph Yiu, “The Definintive Guide to ARM Cortex M3” available from Amazon, Barnes & Noble, etc. Some people have called this “the datasheet, written in English”

Some things to bear in mind while getting started:
Remember, TrueSTUDIO® is based on Eclipse. Eclipse is a very configurable environment with lots of options. You don’t want to use some of them as you are beginning, so stick to the Quick Start Guide. I’ve logged a lot of time with these tools, and have not been able to break them by sticking to the basics.

On my laptop, the ST-LINK has an annoying habit of preventing it from booting up or coming back out of hibernation if it is plugged in. Unplug it in these circumstances, and then plug it back in. ST has a new dll coming soon that will probably fix this.

From time to time, we see customers having some issues with the debugger, so check out: http://www.atollic.com/index.php/kb/3-debugging for some good info on common problems. 

If you want to see a demo of the Atollic development tools go to our web site www.joral.ca and sign up for a FREE Webinar.

• A C/C++ compiler for x86 so you can develop and test  your algorithms in a familiar environment before you commit to hardware
• A UML diagramming tools for expressing the state behavior of your system for specification development and documentation
• Code review management tools
• Clients for bug tracking and revision control 

All of this cool stuff is “built in,” not “added on.” The last two items are particularly hard to find, even in tools costing several times more than the cost effective entry price for  TrueSTUDIO®.  

How hard is it to learn new tools? Well, most developers say the thing they hate the most about using new tools is the learning curve. They have a point. Learning new tools is often a combination of trial and error, and having to wade through reams of dull, turgid, and in many cases, dubiously organized documentation. Atollic has broken ground in this area as well with video tutorials. It is so much nicer to be shown how to do the important and cool stuff by an expert professional than to teach yourself how. Check out

http://www.atollic.com/index.php/videotutorials for the latest and greatest info. Recently posted tutorials cover the Eclipse editor (which is fantastic) the C/C++ grammar search and an introduction to using the version control client. 

These tutorials will have you up and running in no time. Check ‘em out!

Features of Opella-XDS100v2 include:
• Fast, easy-to-install USB 2.0 High-Speed Interface (480Mb/s)
• “Thumb-sized”
• Support for TI devices
including OMAP, DaVinci,
TMS320C6000, TMS320C5000,
TMS320C2000 and TMS470
families
• Wide target voltage range:
1.8V to 3.3V. Opella-XDS100v2
detects and automatically
configures for the appropriate
target voltage
• Target JTAG clock rates from 1MHz to 6MHz with full support for adaptive clocking (RTCK) of debug data
from target
• 14-pin and 20-pin (compact TI) JTAG target connectors supported
• USB powered (no external supply required)
• LED to show USB status
• All software drivers required for operation with CCS are provided by TI as part of the CCS installation
package (see below for download details)
• Support for JTAG reset, Power-on reset and Wait-in reset modes via EMU pins

 There is a nice wiki at: http://tiexpressdsp.com/index.php/XDS100