Using Microsoft Visual C++ Express to compile RVISS model

One of the great things about RealView Instruction Set Simulator (RVISS/ARMulator) is that it supports creating device models. However, you would need to have Microsoft Visual C++ to compile the models. Thankfully, since 2005, Microsoft has offered a free version within its Microsoft Visual Studio Express Editions. (Of course, you need to eventually register to use it indefinitely and if I am not mistaken the registration requires you to run the dreaded "genuine system check".) It comes complete with a nice IDE. This is a far cry from what we would have got from Microsoft Visual C++ Toolkit 2003 long time back.

The easiest thing is to use an existing device model from RVDS installation as a base and modify it from there. For example, let assume you want to use the timer model as a base. You should be able to locate file timer.c and folder timer.b in RVARMulator\ExtensionKit\1.4.1\win-32-pentium\armulator in your RVDS installation folder. Make copy of each into mytimer.c and mytimer.b, respectively. You should be able to locate the Makefile within the mytimer.b folder. In the Makefile, rename all 'timer' occurrences into 'mytimer' and 'Timer' into 'MyTimer' in the Makefile. You could choose any other names you like for 'mytimer' and 'MyTimer', of course.

The best way to compile the device model is to use the "Visual Studio 2005 Command Prompt" from the Start menu > All Programs > Visual C++ 2005 Express Edition > Visual Studio Tools. This custom command prompt sets up the appropriate environment variables to effectively use MSVC++ Express from the command line. If you prefer to configure your own environment variables, make sure you add <install>\VC\INCLUDE into INCLUDE, <install>\VC\LIB and <install>\Common7\IDE;<install>\VC\BIN into Path, where <install> is where you have installed MSVC Express. In particular, if you forgot to include <install>\Common7\IDE;, you would get this when you issue nmake:

cl /c /Za /I..\.. /I..\..\..\armulif /I..\..\..\rdi
   /I..\..\..\clx /D_CONSOLE /D_MBCS /DNLS /nologo
   /W3 /GX /GR /WX -DRDI_VERSION=151 -DARM10MODEL
   /O2 /G6 /MD /DNDEBUG
   /DARM_RELEASE="\"RVARMulatorISS1.4.1\""
   /DBUILD_NUMBER=290 /Iderived  /Fomytimer.obj
   ..\..\mytimer.c
NMAKE : fatal error U1077: '...\cl.EXE' : return
   code '0xc0000135'

And if you explicitly issue the linking command above you would get an "mspdb80.dll not found" error. So make sure <install>\Common7\IDE in your Path environment variable.

Once you have got the environment variables out of the way, when you issue nmake you would still get a small error as shown below:

..\..\..\armulif\perip_sordi.h(184) : error C2220:
  warning treated as error - no 'object' file
  generated
..\..\..\armulif\perip_sordi.h(184) : warning C4996:
  'sprintf': This function or variable may be unsafe.
  Consider using sprintf_s instead. To disable
  deprecation, use _CRT_SECURE_NO_WARNINGS. See
  online help for details.
D:\msvcx\VC\INCLUDE\stdio.h(345) : see declaration
  of 'sprintf'
NMAKE : fatal error U1077: '...\cl.EXE' : return
  code '0x2'

ARM has chosen to treat every warning as error with option /WX. Nobel, yes, but it is not future-proof. Apparently, with the latest Visual C++ sprintf and other buffer clobbering functions that do not specify the buffer length would generate a warning. Removing the option from the Makefile would do the trick.

RVDS ARMulator and GNUARM-compiled binaries

I have started to use the ARMulator , which is also called the RealView Instruction Set Simulator (RVISS). I was interested to see if the binaries compiled using the GNUARM toolchain could work with the ARMulator. Specifically, I was hoping that the input/output (from printf or fgets, for example) could be done from within the RealView Debugger (RVD) session itself. To my surprise, the GNUARM-compiled binaries would not show printf output when ran using the RVD/ARMulator even though they worked just fine with GDB. I have customized my crt0.S, so that was the first place I looked. In addition, writing a simple code using printf and fgets and compiling it using GNUARM without using my custom crt0.S seemed to work. Lo and behold, after comparing my crt0.S and the default one within the GNUARM distribution, I found that I had failed to call initialise_monitor_handles in my crt0.S. Doing this after stack initialization and BSS clearing fixed the problem.

(Apparently, the problem above only appears in GNUARM toolchain from gnuarm.org. The toolchain from CodeSourcery does not exhibit this problem. In fact, the latter does not even have the initialise_monitor_handles function. Oh, well.)

RealView Development Suite and Eclipse

I am starting to use RVDS from ARM. I'm using it mainly for its debugger (RVD) and its simulator (RVISS). I don't know if I will ever use the CodeWarrior IDE that comes with it. However, since ARM supports a number of Eclipse plugins for RVDS, and I have been using Eclipse for most of my embedded work, I thought I would give the plugins a try.

Download the Eclipse plugins and documentation from the ARM website. Even though the RVDS Eclipse plugins page mentions only Eclipse 3.1 and CDT 3.0.0, they work just fine with Eclipse 3.2 and CDT 3.1.0 I am using.

To install the plugins, simply follow the instructions in the RVDS Eclipse Plugins User Guide. Once installed, you can start creating your first RVDS "Hello World!" program in Eclipse. Alternatively, follow the User Guide to create an ARM or ARM/Thumb interworking project.

The User Guide also mentions that GNU Make is required and we should be able to use either the one from Cygwin or from MinGW. I find, however, that if you use Cygwin Make, the first build of a project will succeed but subsequent builds will fail with this error:

hello-rvds.d:6: *** target pattern contains no `%'.  Stop.

Or something to that effect. It has something to do with the Cygwin Make program inability to understand Windows full pathname which includes the drive letter followed by a colon. So, your only option is to download the GNU Make from MinGW. It is an installer. Once installed, put the path to the Make program in your PATH environment variable. Since the program is named mingw32-make.exe, which is different from the one for Cygwin, you do not have to worry about name clash.

One last detail, you also need to replace the default make with mingw32-make in your project properties > C/C++ Build > Build Settings as shown below: