Deprecated: preg_replace(): The /e modifier is deprecated, use preg_replace_callback instead in /home/ajile710/public_html/forum2/includes/bbcode.php on line 483
aJile Systems, Inc. • View topic - FAQs about Software Tools JEMBuilder and Charade

FAQs about Software Tools JEMBuilder and Charade

Discussion regarding tools such as JEMBuilder/Charade/JDEBUG etc.

Postby admin » Sun Nov 05, 2006 7:45 am

Charade interferes with running program

On the PC104, Charade seems to interrupt the system every half second or so for about 15 msecs. If you're using the heap meter or anything else, it interrupts things more often and for longer. This in turn causes Periodic Threads to not beat on time and also it causes System.currentTimeMillis() to slow down. In fact if you have heap meter on at 5HZ, then System.currentTimeMillis() loses 1 second every 20 or so. But even if you have Charade doing nothing, you lose 1 second every 45 or so. So is there any way to tell Charade to stop interrupting things without exiting Charade?

JTAG operations on the JEM2 are very intrusive. This is not true on the new aJ100. To minimize the amount of JTAG opeations, you could

* 1) remove all polls
* 2) close the heap-o-meter
* 3) turn off charadeIO via the "sw tx off" command in Charade.

Charade polls the board to check if the program is trying to dump data through the charadeOutputStream.

Also you could build you code to run off Flash memory and thus not using Charade at all. You can use JEMBuilder to configure to build for Flash then use Charade to program the Flash memory. You can restart the program any time by pushing the reset button. Remember to remove the Jumper J1 to be able to program into Flash with Charade.
admin
Site Admin
 
Posts: 80
Joined: Sat Oct 28, 2006 6:14 am

Postby admin » Sun Nov 05, 2006 7:46 am

Slink errors when build a CLDC build

I get the following errors when building a CLDC program:

**(E) unable to find class "java/io/FilterInputStream" referenced by "pc104/StorageExample/App"
**(E) unable to find class "java/io/FilterOutputStream" referenced by "pc104/StorageExample/App"

Please make sure that the bootclasspath property is being setup properly for the compiler. CLDC requires bootclasspath to be specified for javac to avoid bringing in parts of the host based runtime. An example for CLDC is: bootclasspath=c:/j2me_cldc/bin/api/classes
There is additional detail on managing your classpath when using J2ME at: http://developer.java.sun.com/developer ... t1218.html
admin
Site Admin
 
Posts: 80
Joined: Sat Oct 28, 2006 6:14 am

Postby admin » Sun Nov 05, 2006 7:47 am

My program hangs in com/ajile/jem/RTS_DLink.invokeResolveClassMethodRef(II)V

The method com/ajile/jem/RTS_DLink.invokeResolveClassMethodRef(II)V is a "trap handler" which is automatically invoked by the VM when a method cannot be located. Usually this happens when the static linker removes the method because analysis determined that the method was not directly called from within your program.
Typically the solution is to instruct JemBuilder to retain the class in the build. You can do this by naming the class on JemBuilder's 'forName' page or on the 'More Classes' page.
admin
Site Admin
 
Posts: 80
Joined: Sat Oct 28, 2006 6:14 am

Postby admin » Sun Nov 05, 2006 7:47 am

How can I verify if CharadeDrv is working correctly under Windows 2000?

To verify that CharadeDrv is installed and working properly under
Windows 2000, do the following steps:

1. Open the "Control Panel"
2. Open "System" item
3. Click on "Hardware" tab
4. Click on "Device Manager" button
5. Click on "View" in the bar on top
6. Select "Show hidden devices"
7. Expand the "Non-Plug and Play Drivers" by clicking on its + sign
8. Find "CharadeDrv" in the list. If it's not there, it is not installed.
9. Right click on "CharadeDrv" and select "Properties" from the menu
10.Verify that "CharadeDrv" is working properly
admin
Site Admin
 
Posts: 80
Joined: Sat Oct 28, 2006 6:14 am

Postby admin » Sun Nov 05, 2006 7:47 am

How do I view the call stack for non active threads?

Charade contains the command "show thread" or "sh th". This command displays all the threads in the system.
admin
Site Admin
 
Posts: 80
Joined: Sat Oct 28, 2006 6:14 am

Postby admin » Sun Nov 05, 2006 7:48 am

How can I optimize the various heap settings in JEMBuilder?

The Exec Heap is already sized for minimum memory usage. This size should not be adjusted for normal builds. The Exec Heap is used for the creation of the Garbage Collector (GC), Heap Monitor, and Idle threads and their associated data structures. The Exec Heap is also used for the creation of any objects during low level driver intializations. Garbage collection is not performed on the Exec Heap since the objects created are always needed by the target system.
All user threads including the main thread are created from the PCL heap (user heap). All objects created by the application use this help. Hence, the size of this heap is very dependent on the application.
The user heap can be adjusted in the "Initial Heap Size" field on the JEMBuilder Memory page. Sizing this heap too small will result in "out of memory exceptions". The Heap Usage Meter in Charade can also be used to roughly estimate the amount of memory needed for the heaps. The size indicated by the heap usage meter will normally increase as the application runs and decrease after GC completes.
admin
Site Admin
 
Posts: 80
Joined: Sat Oct 28, 2006 6:14 am

Postby admin » Sun Nov 05, 2006 7:48 am

How can I build dual JVM applications using JEMBuilder?

aJile processors currently support two JVMs running in distinct contexts on their targets. The two JVMs operate independently of each other and run in distinct memory spaces. They are not allowed to share peripheral devices: a peripheral device must be wholly under the control of one JVM.

1. Creating a Dual JVM Build.

JemBuilder can be used to create a dual JVM build in much the same way as a single JVM build is created.

1. Select File | New Project.
This starts a wizard that walks the user though the initial configuration process of creating a new project.
* Step 1: Specify an output directory for placing the build output files.
* Step 2: Select a runtime and a configuration for this build.
Click on Finish to open a new wizard for the the creation of a new JVM Creating a new JVM
2.
* Step 1: Enter the name of the JVM. Default name for the first JVM is JVM0
* Step 2: Enter the fully qualfiied class name of the class that defines the main
* method for this build Step 3: Provide the class path that was used to compile the files being linked
* in this build Step 4: Select the peripherals that will be required for this build. Note that
any peripherals selected for this JVM build will not be available for the second JVM build. Clicking Finish will complete the creation of this JVM build. To create a second JVM
3. Select File | New JVM. This will open the wizard for the creation of a new JVM. This time the default name of the JVM is JVM1. Step through the wizard as described in the previous bullet.

The user should now see three folders in the left window in JemBuilder:

* Project
* JVM0 (default name)
* JVM1 (default name)

(Note: If the user overrides the default name, there is no check to determine if the name specified has already been used for the first JVM. Two JVM folders with the same name, representing the two distinct JVMs created, will appear in JemBuilder's left window.)

2. Specifying Memory Ranges on Target

If the user opens the Project | Memory page in JemBuilder's left window, (s)he will see the default settings for RAM and ROM specified in the appropriate boxes. These values are determined by the target configuration selected for the build. Users are not advised to modify these default values unless they are very familiar with the environment and feel comfortable calling themselves experts.

* A RAM configuration will provide the correct values for the RAM start address
and size as default. The default values for the ROM start address and ROM size are zero for a RAM configuration. In this configuration, program RAM and program ROM data are both loaded in SRAM on the target. Prior to loading, it is assumed that the target is configured correctly for loading into SRAM.

Note: This configuration is primarily intended for development and debugging, where it is expected that several changes to the program code/data are likely to take place often. No memory protection between VMs or between VMs and trusted space is provided when executing applications in this configurations.
* A Flash configuration provides the correct values for both the RAM and ROM
start addresses, and respective sizes as default. The ROM information corresponds to the Flash memory on the target. Once again, the target needs to be configured for Flash loads in order for the build to be loaded correctly into Flash memory.

Note: Memory protection is supported in this mode. This configuration is intended to be used when the program under development is stable and is ready for deployment.

The entries for RAM and ROM in the Project | Memory page specify the entire memory available on the target for the two JVM builds.|

3. JVM Memory Ranges

The memory available to each JVM can be specified in the corresponding JVMx | Memory page. The user has two choices:

* Check the "Locate JVM in next available memory" box

This is the simplest choice. The linker/loader will automatically load the program code/data in the next available free location in memory. The user does not need to be concerned with the size of program code/data and where it is loaded in memory on the target. If this JVM is the second JVM, it will be auto-loaded in memory immediately following the first VM's program data and heaps (and read-only data for RAM configuration builds).

If this choice is selected, the user is required to provide the desired value for the Initial Heap Size field in the JVMx | Memory page. This field specifies the minimum user heap size (bytes) required by the application.
* Specify the absolute addresses for RAM and ROM where the JVM will be located.

To exercise this option, make sure the "Locate JVM in next available memory" box is unchecked.

The user can determine where exactly to locate the application. The program RAM and ROM will be located starting at the start addresses specified. If the specified region of memory is insufficient, Jemcfg will report an error and abort the build process when this condition is detected.

If RAM start address and size are left as 0x0, the RAM component of the application code/data will be autolocated. (Note, if the user elects to do this, (s)he is required to provide the desired value for the Initial Heap Size field in the JVMx | memory page.)

If ROM start address and size are left as 0x0, the ROM component of the application code/data will be auto-located immediately following the RAM region.

Note: The memory range 0..0x4800 (approx) is reserved for runtime executive use. If a RAM/ROM region specified by the user overlaps with this reserved range, jemcfg will report an error. The error message will indicate the exact reserved upper bound for that build, and suggest that the start address of the memory region specified by the user exceed this value.

The user may choose to specify RAM and ROM memory regions using any combination of the above two choices.

* Auto-locate RAM and ROM regions for both JVMs
* Check the "Locate JVM in next available memory" box for both JVMs. Auto-locate one of the JVMs and specify the memory regions for the other JVM
* For the JVM to be auto-located, check the "Locate JVM in next available memory" box. For the other JVM, specify the start addresses of the RAM and ROM regions. For either VM, specify the RAM memory region but auto-locate the ROM memory
* Specify the RAM start and size fields, and set the ROM start and size fields to 0x0. For either VM, specify the ROM memory region but auto-locate the RAM memory
* Specify the ROM start and size fields, and set the RAM start and size fields to 0x0. (Note requirement on specification of Initial Heap Size .) For both VMs, specify the ROM and RAM memory regions
Specify non-zero start and size fields for RAM and ROM areas for both JVMs.

4. Executive and User Heaps

The application build requires the specification of two heaps: the executive heap and the user heap.

The executive heap is used by the runtime system during initialization for the creation of the Garbage Collector (GC), the Heap Monitor(s), and Idle threads and their associated data structures. It is also used for the creation of any objects during low level driver intializations. Garbage collection is not performed on the executive heap since the objects created are always needed by the target system. The size of the exec heap must always be specified in the JemBuilder JVMx | Memory page. In most cases, the default value that is provided can be used without change.

All user threads including the main thread are created from the PCL heap (user heap). All objects created by the application use this heap. Hence, the size of this heap is highly dependent on the application. A very small heap will result in "out of memory exceptions". The Heap Usage Meter in Charade can be used to roughly estimate the amount of memory needed for the heaps. The size indicated by the heap usage meter will normally increase as the application runs and decrease after GC completes. Another method to determine the state of the heaps is to stop the application and use the "show heaps" command in Charade.

The user heap may be provided in one of two ways:

* Enter the desired user heap size in the "Initial Heap Size" field on the JEMBuilder
* JVMx | Memory page. The user has a choice of using auto-location of the RAM region for that JVM or specifying the desired memory range. If the user opts for auto-location, the auto-locator will locate the program RAM, starting at the next available free memory, followed by the executive heap and finally the user heap. Set the desired user heap size in the "Initial Heap Size" field on the JVMx | Memory page to 0x0
The user must specify the desired RAM memory region. All RAM memory in that region that is left after locating the program RAM and executive heap will be used as user heap. The actual size of the allocated user heap will be reported by jemcfg.
admin
Site Admin
 
Posts: 80
Joined: Sat Oct 28, 2006 6:14 am

Postby admin » Sun Nov 05, 2006 8:07 am

Is there a command line interface to JemBuilder?

You can indeed invoke JemBuilder from the command line, but not by invoking JemBuilder.exe, because that executable will always launch the GUI interface to JemBuilder.

In order to invoke JemBuilder from the command line, you must invoke the main method of com.ajile.jembuilder.JemBuilder through the Java interpreter as follows:

java -cp C:\aJile\JemBuilder\JemBuilder.jar -Dlax.root.install.dir=C:\aJile
com.ajile.jembuilder.JemBuilder C:\aJile\JemBuilder\library.properties
myproject.ajp [configurationsDirectory]

The first argument to

com.ajile.jembuilder.JemBuilder.main()

is the pathname to the "library.properties" file, normally in the JemBuilder directory

The second argument is the pathname to the .AJP file.

The third (optional) argument is the directory which encloses the configurations.
aJile has also set up an Ant task which invokes JemBuilder from within an Ant script; this task can be run on individual .AJP files, or can scan a directory tree for all .AJP files.

aJile doesn't currently ship the Ant support with our tools, but we will send it to anyone who might find it useful.
admin
Site Admin
 
Posts: 80
Joined: Sat Oct 28, 2006 6:14 am

Postby admin » Sun Nov 05, 2006 8:08 am

How do I build and run a program from flash memory of the aJ-EVB(m)?

There are three basic steps you must follow to prepare a program for execution from flash memory and to execute that program:
1. Rebuild the program with a flash memory configuration

JemBuilder's Project|Properties dialog box allows you to change the
target configuration to be used with a given development board.
Use the flash configuration which corresponds to the board you are using.

For example, the aJ100EVB RAM configuration is named "aJ100EVBConfiguration"
and the corresponding flash configuration is named
"aJ100EVBFlashConfiguration"

Generally it is good practice to maintain different JemBuilder project files
for RAM and flash builds, and to place these differing builds in directories
named to reflect their contents. This avoids trying to figure out why
the program won't run and Charade displays the message "BIST Fail".

2. Switch the memory mapping jumper or switch to the "flash" position

The documentation for the development board will tell you which switch
or jumper is used to alter the memory mapping for flash and RAM.

On the aJ100EVB, switch S4 must be in the "Flash at 0" position to enable
loading and executing from flash. The aJ100EVB is shipped with switch S4
in the "SRAM at 0" position.

Typically it is good practice to halt and reset the target board
with Charade before switching the flash jumper or switch.

3. Load the program onto the target board

Use Charade to load the program as usual, with the File|Execute
command and the "load.sod" file.

Note that JemBuilder places additional commands in the "load.sod"
file to erase the contents of flash memory before loading the program.

Use Charade to reset the processor and run the program. Once the program is loaded into the flash memory and the memory switch is in the Flash position, the program will start running at power on or reset.
admin
Site Admin
 
Posts: 80
Joined: Sat Oct 28, 2006 6:14 am

Postby admin » Sun Nov 05, 2006 8:09 am

JemBuilder reports an error "bad jvm version, at offset 8"

There is an incompatibility with JemBuilder (actually, the linking tool 'slink') and the default JVM "version" placed within class files produced by the JDK 1.4 'javac'
This incompatibility exists in 'slink' version 6.17 and all earlier versions.
You have two choices:
1. Run the JDK 1.4 'javac' with the '-target' option set to the value '1.1' 2. Revert to using the JDK 1.3 to do your compilations
aJile will correct this problem in a future release. There is no difference between the execution behavior of the class files produced by the 'javac' compiler's "-target 1.1" option and the
For more detailed information on how JDK 1.4 differs from JDK1.3 in this regard, see:
http://java.sun.com/j2se/1.4/compatibility.html
Here is a relevant excerpt from that documentation:

As of J2SDK 1.4.0, the javac bytecode compiler uses "-target 1.2" by
default as opposed to the previous "-target 1.1" behavior. See the reference page for the javac compiler for descriptions of these
behaviors.
admin
Site Admin
 
Posts: 80
Joined: Sat Oct 28, 2006 6:14 am

Postby admin » Sun Nov 05, 2006 8:10 am

Can Charade run in a batch mode?

To run Charade in a batch mode (executing a macro script in non-interactive mode), create a file containing the macro script to be executed. It's a good idea to test the script in interactive mode first to make sure that it does produce the desired results. The batch marcro script must begin with "SWITCH BATCH ON" and ends with "EXIT". Use the following command to execute a batch file:
"c:\ajile\Charade\Charade.exe [batch_file] c:\ajile\Charade\charade.wcf c:\ajile\Charade\charade.cfg"
This command assummes that aJile software has been installed to the default directory c:\ajile. Otherwise, modify the path names to match the actuall directory.
admin
Site Admin
 
Posts: 80
Joined: Sat Oct 28, 2006 6:14 am

Postby admin » Sun Nov 05, 2006 8:11 am

It takes a power cycle after a flash load to run without Charade

To stop the target processor, Charade sends a halt command across the JTAG port. This sets a halt flag in the processor. Just unhooking Charade and pressing the reset button does not clear this halt flag on the target. The target must be powered down to clear this flag.

Alternatively, before unhooking Charade you can press "run". This will cause the halt flag to be cleared on the target.
admin
Site Admin
 
Posts: 80
Joined: Sat Oct 28, 2006 6:14 am

Postby admin » Sun Nov 05, 2006 8:17 am

How can I determine the memory locations which are not reserved for use by any JVMs?

When you use JEMBuilder to build a multiple JVM application, it will configure the memory area used by each JVM, either automatically or manually. These memory areas are private and protected for each JVM.
The memory outside of these areas may be "shared" by all JVMs in the sense that the memory will not be used by any of the JVMs.
Note that this "sharing" is by convention only; the JVMs alone determine what "protocol" must be used to ensure that the "sharing" is done properly.
There are two ways to determine the locations of unused memory areas:
1. Automatic memory allocation by JEMBuilder:

One of the files generated by JEMBuilder has the extension .jcf.
This file contains the information about the highest used memory
location (base + size) for each of the JVMs. The unused memory
area is beyond the highest used external memory location.

2. Manual memory allocation:

In JEMBuilder, you can manually specify the memory allocation for
each JVM. If you leave a gap between the memory areas used by the
JVM, the memory in the gap is unused by any of the JVMs.

Once you've located the unused memory area(s), you can use rawJEM method calls to read and write physical memory. Each JVM is responsible for observing whatever ad-hoc "protocol" has been implemented.
admin
Site Admin
 
Posts: 80
Joined: Sat Oct 28, 2006 6:14 am

Previous

Return to Tools

Who is online

Users browsing this forum: No registered users and 0 guests

cron