Batch build using IAR tools

Question

I am trying to do a batch build of a project using IAR tools. The processor is a CC2530, and it builds fine in the IDE. I have followed the documentation for batch build (Project/Batch Build) and created a .cspy file that is suppose to be my batch file, but in the comments in that file it indicates that I need a debug file (.ubrof) to execute with it. I can't find a .ubrof file and I have searched the whole project directory structure. Also, I want my batch build to build a production version without the debugging information.

Where do I get a .ubrof file? How do I do a production batch build using IAR tools?

Answer 1

My understanding of your question is that you want to build the firmware image using a command line from within a batch file. I use the IAR tools for MSP430 and AVR32 processor families and the command line used to invoke the IAR build process from the command line is

iarbuild "Project_File.ewp" -make BUILD_NAME -log info

where BUILD_NAME is the build configuration ("Debug" or "Release" are the two default options). The syntax of the iarbuild command is in the Embedded workbench manual.

The UBROF file is the binary output file that the tools produce and that you fould normally load into your target for debugging. I would normally have the tools produce a UBROF file for debugging and a hex or s-record image file to be used for device programming in production.

Answer 2

.cspy is related to the C-Spy debugger; you do not need it to build the project.

.ubrof is an object file format used by IAR, it is the result of a successful build (if the project is configured to produce such a file).

The IAR command line build utility (iarbuild.exe), and the C-Spy command line utility (cspybat.exe) are discussed here

Answer 3

It is also possible to call the iar compilers/assemblers/linkers from the command line. This might be beneficial, if you already have some build framework (make, cmake, scons, etc) -- you can then use other toolchains for the same sources. For a example a native toolchain to generate unit tests from your code.

The big disadvantage of this approach is that it requires an additional (duplicate) description of what is already in the iar project files: Which files to use, which compile flags to apply. This clearly violates DRY.