This release note covers version v10.0r4. It describes the changes and new features of all TASKING 68K/ColdFire products since v9.2. The following parts are described:
The solved and known problems are not part of this release note, they are described in a separate file, Solved_10_0r4.html, delivered with the package.
Sometimes developer boards have memory areas which are not readable because this influences the debug interface. The result is that all registers seem to be zero in the register window of CrossView Pro and cannot be modified anymore. If this is still the case after a target reset, it is probably because CrossView Pro tried to read one of those memory locations directly after the reset. This happens if the memory window shows an invalid memory area or the stack window is open and the stack pointer contains an invalid address. To overcome this, close all CrossView Pro windows and reset the target. Open the CrossView Pro register window and modify the registers containing an invalid address. Now it is save to reopen other CrossView Pro windows.
All tools have been adapted to support long file names and directory names, which may contain spaces.
The table below lists the derivatives that were added between revisions v10.0r1 and v10.0r3 (no derivatives were added in v10.0r4).
|
family |
v10.0r1 |
||||||||||
|
ColdFire |
MCF5204 |
MCF5206 |
MCF5206E |
MCF5249 |
MCF5249L |
MCF5272 |
MCF5280 |
MCF5282 |
MCF5307 |
||
|
MC680x0 |
MC68LC040 |
MC68EC060 |
MC68LC060 |
||||||||
|
Dragonball |
MC68EZ328 |
MC68VZ328 |
MC68SZ328 |
||||||||
|
family |
v10.0r2 |
||||||||||
|
ColdFire |
MCF5214 |
MCF5216 |
MCF5232 |
MCF5233 |
MCF5234 |
MCF5235 |
MCF5270 |
MCF5271 |
MCF5274 |
MCF5275 |
MCF5281 |
|
family |
v10.0r3 |
||||||||||
|
ColdFire |
MCF5207 |
MCF5208 |
MCF5211 |
MCF5212 |
MC5213 |
||||||
Introducing the P&E USB Multilink execution environment. Use the following instructions to enable it from EDE:
select 'project | project options... | CrossView Pro | Execution Environment' PAGE
click 'Background Debug Mode (BDM)' RADIOBUTTON
click 'Communication Setup' LINK
click 'USB communication' RADIOBUTTON
The EDE in v10.0 has been highly improved and reorganized. The menu structure has changed: all items previously included in the EDE menu are now distributed over the other menus. All dialogs for setting the options are now integrated in a single Project Options dialog, accessible from the Project menu.
|
The changes in EDE may have some implication for your application. Although EDE converts the settings from your project file of previous versions, it is still recommended to double check your project options. |
You can navigate through the different option dialogs via the expandable tree view as you are familiar with from other Windows based applications. This new way of presenting the options guarantees that you will not lose the complete overview.
To allow users to quickly familiarize themselves with the Avnet MCF5282 developer board, the following examples have been added:
\examples\Avnet-MCF5282\blink.pjt
Configures MAPBGA pin K13 for its secondary function (PCT0) such that it will be able to command LED D5 on Avnet's MCF5282 developer board. It continues to toggle the pin at repeated intervals.
\examples\Avnet-MCF5282\bootflash.pjt
Using the Avnet MCF5282 developer board this exampe outlines an implementation of a self bootable program image. The program image copies itself from internal flash memory to SDRAM memory and then launches the real application program. The real application program in this case is a simple memory check algorithm that checks only half of the installed SDRAM memory (Micron's MT48LC8M16A2TG-8E, 128 Mbyte). First the memory is filled with a predefined value during which LED0 will blink. Next the memory is compared during which LED1 will blink. Upon success both LED's will be set.
\examples\Avnet-MCF5282\uart.pjt
This sample program initially configures UART1 for polled IO. It requires a terminal program configured for 115200 Bps, 8 data bits per character, no parity and 1 stopbit per character. The program overloads low level character routines _read() and _write() such that they can drive UART1 using polled IO. This allows standard C IO routines to drive UART1. This is demonstrated by means of printf() and getchar() that will be redirected to your terminal program. Using these two functions you will be offered to switch to interrupt driven IO. Interrupt driven IO will consist of simply echoing the character that was received from the terminal program.
Two simple examples to allow users to quickly familiarize themselves with Freescale's M5208EVB and M5213EVB developer boards.
\examples\Freescale-M5208EVB\hello\M5208EVB_hello.pjt
This example prints "Hello World!" on Freescale's M5208EVB developer board. The application program is located from address 0x4000.0000 and CrossView Pro will use mot_m5208evb.cmd to properly initialize M5208EVB before downloading the application. The project assumes the P&E USB Multilink debug interface is being used to connect to M5208EVB. Options file m5208evb.opt can be used to restore the project settings to their original state in case they changed. In addition it can be used as a quickstart options file for user application programs.
\examples\Freescale-M5213EVB\hello\M5213EVB_hello.pjt
This example prints "Hello World!" on Freescale's M5213EVB developer board. The application program is located from address 0x8000.0000 and CrossView Pro will use mot_m5213evb.cmd to properly initialize M5213EVB before downloading the application. The project assumes the P&E USB Multilink debug interface is being used to connect to M5213EVB. Options file m5213evb.opt can be used to restore the project settings to their original state in case they changed. In addition it can be used as a quickstart options file for user application programs.
A simple example for Axiom's CMM-5235 developer board.
\examples\Axiom-CMM5235\hello\CMM5235_hello.pjt
This example prints "Hello World!" on Axiom's CMM-5235 developer board. The application program is located from address 0x0000.0000 and CrossView Pro will use ax_cmm5235.cmd to properly initialize CMM-5235 before downloading the application. The project assumes that the P&E ColdFire BDM debug interface (Parallel Port) is being used to connect to CMM-5235. Options file cmm5235.opt can be used to restore the project settings to their original state in case they have changed. In addition it can be used as a quickstart options file for user application programs.
A simple example for MCT's MEGA332 developer board.
\examples\MCT-MEGA332\hello\MEGA332_hello.pjt
This example prints "Hello World!" on MCT's MEGA332 developer board. The application program is located from address 0x0000.0000 and CrossView Pro will use mct_mega332.cmd to properly initialize MEGA332 before downloading the application. Options file mega332.opt can be used to restore the project settings to their original state in case they have changed. In addition it can be used as a quickstart options file for user application programs.
File system simulation enables the application on the target board to use system calls (such as open, read, write) that are handled by the host system file I/O services. These files can be read directly from the host system, and output can be written to a file on the host system or in a CrossView Pro window. File system simulation is available for all execution environments.
The low-level I/O functions such as _open(), _close(), _read(), _write() are implemented in the C library to use File System Simulation. These functions redirect high-level I/O calls such as printf() and scanf() type functions through CrossView Pro's FSS feature, allowing you to perform stdin, stdout and stderr stream I/O by just using these standard C library functions.
The libraries have been optimized to only attach the file I/O routines if the application actually uses file I/O. The default I/O streams stdin, stdout and stderr are opened on the fly whenever file I/O is used; this behavior is transparent to the user. It is no longer necessary to inform CrossView Pro about the use of any streams.
There can be some pitfalls when mixing pre v10.0r1 I/O routines (Simulated I/O) with this new FSS feature:
Pre-built pre v10.0r1 object modules or libraries
Pre-built third party object modules or libraries
C++, C and Assembly source code which directly interfaces on the Simulated I/O functions.
If you have either one of these situations, then do the following:
Rebuild every C or C++ module that use I/O routines from their source code.
Check if your third party modules and libraries use I/O routines which are v10.0r1 compliant. If not, rebuild them yourself if you have the source code or contact your third party vendor if you are not sure about v10.0r1 compliancy.
Change your C++, C and Assembly modules to interface on ANSI-C I/O routines.
If your source code interfaces directly on the _simi() and _simo() Simulated I/O functions, then please be aware that the v10.0r1 libraries do not use these functions anymore. They use FSS instead which cannot be mixed with Simulated I/O in any way. Although CrossView Pro still supports Simulated I/O, it would be highly advisable not to use the _simi() and _simo() Simulated I/O functions directly from your source code but use regular ANSI-C printf() and scanf() type functions, instead which ensures portability of your application.
Because FSS buffers its data by default, just as you were used to with Simulated I/O, please beware that you either use the "\n" newline character to terminate the information you are printing with printf() type functions, or use the fflush() function to flush this buffer in order to force FSS to display its information on the CrossView Pro Terminal Windows or to write it into a file. Neither CrossView Pro nor the FSS implementation in the library will perform this operation for you. For example, to clear the entire screen, you can enter:
printf("\033[H\033[2J");
fflush(stdout);
Please see the section about File System Simulation in the CrossView Pro manual for details on attaching your own streams to certain CrossView Pro Terminal Windows and how to capture and feed the default I/O streams stdin, stdout and stderr.
The GUI of CrossView has been improved, resulting in a more intuitive and user-friendly interface.
You will be warned if a source file is newer than the download file.
Static variables within a function can be inspected and a
hexadecimal display option in the Data Window has been added.
The
performance of the terminal windows has been improved; scrolling and
updating of windows has become much faster.
You can use the new File | Compare Application... dialog to check if a file matches the downloaded application. This can be useful when you want to check if the program code has been changed, for example due to uninitialized pointers. The same check can be accomplished through the command window with the dcmp command.
It is now possible to save your profiling results. Either you can
use the commands cproinfo and proinfo from the command
window or you can press the Tools | Profiling | Report | Save...
button from the GUI to save the profile report in a file.
Note
that profiling is only available when you use the simulator.
Support for OSEK RADM has been added. CrossView Pro has two additional command line options:
--radm=osek_radm --orti=ORTI-filename
Within EDE choose: Project | Project Options... | CrossView Pro | RTOS Aware Debugging Module. Select OSEK and fill in the name of the ORTI file.
The following Target Interface Package has been added:
\smartmon\boards\mcf5282avn\mcf5282avn.pjt
This project targets SmartMon to the Avnet MCF5282 developer board using the following memory map:
Memory
Range
Note
Application code/data
0x0000.0000 - 0x0100.0000
16M of SDRAM
SmartMon code
0xf000.0000 - 0xf000.e8000
± 58K extended version
Smartmon data
0x2000.0000 - 0x2000.5000
15K trace and 1K variables
Copyright (c) 2004-2006 Altium BV