Support
 
microcontroller
 

8051

Topics in this FAQ area are grouped as follows:

 Back to all FAQs

 

 

Installation

 

Q: How do I install my Raisonance products ?

A: First  activate your software, then check your registration has worked. You can now use your software.

^top

Q: How do I activate my software ?

A: CD Installation:
Follow the instructions

  1. Select the running mode for Ride6: Choose option “with serial number”
  2. At the user information window: Create a user name and add your company information
  3. Serialization: Enter the serial number you have received

Once the installation has completed: Launch Ride6 software:

  1. Verify your software: Go to Help/About, click on 8051 Tool Chain and check the tool capabilities, click OK, close.
  2. Activate your tool: Go to Help/Registration, Enter your serial number in the box and register from the web (the registration process will be performed automatically with this function if your firewall allows it). If your firewall does not allow this, or if you have already obtained an activation code from Raisonance support, click on:

              o        Modify Activation code
              o        Then go to the following page of the Raisonance web site:
                                http://www.mcu-raisonance.com/activation_code.html
              o        Add your company name, your serial number, and copy the serialization code from Ride7.
              o        Click to get your activation code.
              o        When you see the activation code, copy it into the relevant boxes in Ride7.
              o        Click on Register Activation Code.

^top

Q: How do I verify my registration has worked ?
A: Go to Help/About, click on 8051 Tool Chain and check the tool capabilities (the limitation should now correspond to the tool you have bought), click OK, close.

You can now use your software.

^top

 

8051

SIMICE-51 simulator


Q: Why does the I2C peripheral for the 552 microcontroller not work with the simulator?

A: Not all the peripherals of every microcontroller have been (or can be) implemented by the simulator. Their 'views', however, can be seen via the emulator or with a monitor. That is why some of the microcontrollers have a star as a suffix in the 'Options | Debug', window. The star indicates that some peripherals of the microcontroller are not supported. The list below shows which peripherals are not supported on some 8051 devices:

  • ADC 505
  • ADC 504
  • CAN 592
  • SSC 515C
  • CAN 515C
  • ADC 515C
  • I2C 552 

Q: When I simulate my program some local variables are not displayed correctly: what should I do ?

A: Some Raisonance projects need an extended OMF51 format, called OE2, to display properly all local variables.

Make sure you select the OE2 format by checking the box 'Extended 1997 version (OE(2))' in Options|Project|RC51|Object.

Q: How can I simulate external interrupts, that is, how can I generate an edge on a pin that will cause an interrupt to occur?

A: The simplest way is:

  1. Start the debugger,
  2. Put a breakpoint on the first line of the interrupt routine,
  3. Start the program with the GO button,
  4. Open the window for the Port where the pin you want to toggle is,
  5. Position the mouse on the pin you want to toggle until the world 'link' appears
  6. Left click and choose connect to Vcc or connect to ground according to which level (or edge) will trigger your interrupt.

If you want your interrupt to occur at a given time you can connect the pin to a waveform generator rather then switching it manually.

If your interrupt routine is programmed correctly (right address, right priority, right enable mask and so on), the program execution will stop at the breakpoint.

^SIMICE FAQs       ^top

8051

RC-51 compiler

 

Q: What are the limitations of the demo version ?
A: All tools are limited to 4Kb. That means that you cannot compile modules of more than 4Kb, you cannot link modules whose cumulated size is greater than 4Kb and you cannot simulate imported programs greater than 4Kb.

^RC-51compiler FAQs   ^top

Q: Which other C syntax extensions are accepted by the RC51?
A: RC51 in compatible with C51 from Keil. This means that most programs written for the Keil compiler will compile with RC51 with very little modifications or no modifications at all.

^RC-51compiler FAQs   ^top

Q: How do I specify a pointer and its pointed object?

A: A pointer is represented by a * (star) symbol: what is on the left of the star specifies what the pointer is pointing to, what is on the right of the star specifies details about the pointer itself.
Example:
char * ptr;
specifies a pointer named 'ptr' pointing to a character. The character can be anywhere in the memory space (code or data - the pointer is said to be 'generic') and the pointer itself can be anywhere in the data space.
You can specify more details about both the pointer and the pointed object, like in
int code * idata foo;
in this case you declare a pointer named foo, located in idata and pointing to a variable of type int, located in code.
The general rule is as follows (optional means that this part of the declaration is not mandatory):
pointer_storage-class-specifier (optional) pointed_object_definition (optional) * pointer_definition;
where
pointer_storage-class-specifier: one of: auto register static extern typedef at address
pointed_object_definition: type-specifier(optional) pointed_object_qualifier(optional)
remark: type-specifier is recommended; at least one specifier is needed before star
pointer_definition: pointer_qualifier(optional) direct-declarator
type-specifier: one of: void char short int long float double signed unsigned struct-or-union-specifier enum-specifier typedef-name
pointed_object_qualifier: one of: code, data, idata, xdata generic and/or const and/or volatile
pointer-qualifier: one of: code, data, idata, xdata
default space qualifiers: The default space qualifier for the pointed_object_qualifier is: generic.
The default space qualifier for the pointer_qualifier and the pointed_object_qualifier in case the NOGENERIC pragma is defined is:
models TINY and SMALL: data,
model COMPACT:pdata
models LARGE and HUGE:xdata.

More examples:
at 0xA0 char * idata pchar_data;
pchar_data defines a pointer located in idata at the address 0xA0 pointing to a char.
extern int code * data pint_fcode;
pint_fcode defines an extern pointer located in data pointing to an integer located in code.
typedef char data * ptype;
ptype defines the type of a pointer pointing to a char in data. Remember: no pointer-qualifier is allowed with typedef as pointer_storage-class-specifier!

^RC-51compiler FAQs   ^top

Q: How do I define a generic pointer? How do I define a space qualified pointer?

A: A generic pointer is a pointer that can point anywhere in the memory space. A space qualified pointer is a pointer that can only point at a specific space, defined when the pointer is declared. Space qualified pointers are typically smaller than generic pointers, and therefore generate more efficient programs.
A generic char pointer is defined as follows: char * pointer_name;
A Code qualified pointer is defined as follows: char code * pointer_name;
A XData qualified pointer is defined as follows: char xdata * pointer_name;
In addition to specifying where the pointer is pointing you can also specify where the pointer is located (for example, you usually want to locate frequently used pointers in data, because that's the place where they are accessed the fastest)
If you want to define a code qualified pointer located in xdata space, you have to write : char code * xdata pointer_name;

^RC-51compiler FAQs   ^top

Q: When I access elements of the object my pointer is pointing to, the program starts behaving strangely. Why?
A: This is typically due to a non-initialized pointer. Consider the following program:
typedef struct {
int a;
int b;
} mystruct;
void main(void)
{
mystruct *foo;
foo = 1;
foo = 3;
}

Here, you declare the pointer foo and then you try to access elements of the object it points to. However, foo does not point to any well defined object yet, because no object has been assigned to it.

Therefore, when foo = 1 is executed you are going to write the value 1 in some unspecified memory location: this can have different consequences:
- nothing: if foo is pointing to an unused memory location;
- modification of other, unrelated variables;
- modification of some registers, resulting in unexpected program behaviour;
- modification of the code, resulting in bad program execution.
The solution to this problem is to always assign a pointer to an object before using it, as in the following example:
typedef struct {
int a;
int b;
} mystruct;
void main(void)
{
mystruct i;
mystruct *foo;
foo=&i;
foo = 1;
foo = 3;
while(1);
}

^RC-51compiler FAQs   ^top

Q: Where do I find the include file defining the specific Special Function Registers (SFRs) of my derivative ?

A: In the RIDE\inc folder . Choose the *.h file that corresponds to your microcontroller. If it does not exist you can create it by editing one of the existing files and adding the SFRs that you require.

^RC-51compiler FAQs   ^top

Q: My program does not compile because of too many warnings. What can I do?

A: Go to 'Options | Project | RC51 | Messages'. Set the 'Stop after n warnings' limit to a higher value.
To avoid seeing all the warnings you can set "warning level" lower (0 => no warnings are printed, 1 => some important warnings are printed, 2 => all warnings are printed).

^RC-51compiler FAQs   ^top

Q: Are there predefined date and time macros in the 8051 compiler?

A: Yes, the predefined __DATE__, __DATE2__, __DATE3__ and __TIME__ macros exit. Refer to the section 'Predefined Names' in the manual for further information. Note '__' is double underscore.

^RC-51compiler FAQs   ^top

Q: Can I include assembler statements in my C source file? Why do I get error #C125?

A: Yes, you can include assembler in your C source, using the "asm" and "endasm" pragmas but you need a little 'trick' as follows:
1. In Ride7, open 'Options | Project | RCXXX | Object' and select the 'Generate an assembler source file (.SRC)' radio button. If option is not selected the compiler will generate an error #C125.
2. Add a node to your project. This node must be called filename.src and must be *below* the node containing the C source file.
3. Edit the properties of the node containing the C source (right-click on it and choose Properties) and uncheck the box "Include this node in the link of the project".
3. Edit the properties of the node containing the .src file and choose the right assembler in the "Translate with" list.
4. You are now ready to build your project.
Note: although including assembler in your C sources is feasible as explained above, we recommend you would rather investigate the possibility to write all your assembler functions in a separate source file and make the necessary connections between the two modules using the EXTERNAL/PUBLIC keywords.

^RC-51compiler FAQs   ^top

Q: At the end of my program, completely unrelated pieces of code are executed and a lot of errors occur. What is wrong?

A: After the last instruction in the main function has been processed, the program executes a 'RET' instruction, which accesses an undefined stack entry. Therefore, the program can execute code from anywhere in Code space and produce errors. This is because with microcontrollers, unlike PCs, the execution thread cannot be passed back to an operating system.
To avoid this problem just add an infinite loop at the end of your program (example: 'while(1);').

^RC-51compiler FAQs   ^top

 Q: When I simulate my program some local variables are not displayed correctly: what should I do ?
A: Some Raisonance projects need an extended OMF51 format, called OE2, to display properly all local variables.
Make sure you select the OE2 format by checking the box 'Extended 1997 version (OE(2))' in Options|Project|RC51|Object.

^RC-51compiler FAQs   ^top

 Q: When I try to load my program in a non-Raisonance emulator I have an error message 'Unknown OMF record type' : what should I do ?
A: Most non-Raisonance emulators currently support only 'standard OMF51' (OE) debugging format.
Some Raisonance projects need a more complete OMF51 format, called OE2.
If you emulator does not support OE2 make sure you select the standard OMF format by checking the box 'Extended (OE)' in Options|Project|RC51|Object.
Note that using OE for a project that requires OE2 might result in not having access to some local variables during debug.

^RC-51compiler FAQs   ^top

 Q: What does the 'Enable ANSI Integer Promotion Rules' option mean?
A: The 'Enable ANSI Integer Promotion Rules' option (checked by default) tells the compiler to 'promote' the operands of an expression to the type of the biggest operand before calculating the expression itself.
Consider the following example:
char a,b;
int sum;
a = 0x80;
b = 0x80;
sum=a+b;
If the option is checked, a and b are promoted from char (1 byte) to int (2 bytes), before calculating a+b, therefore the result stored in sum will be 0x100.
If the option is not checked, the result stored in sum will be 0 (the most significant bit will be truncated).

Note that working with this option unchecked is not recommended, although it can generate a sligthly smaller code when calculating expressions such as the one above.

^RC-51compiler FAQs   ^top

 Q: How can I port a project originally written for Keil's c51 to Raisonance?
A: Raisonance and Keil compilers are basically 'compatible': this means that to port most Keil projects to Raisonance you just need to recompile and everything will work fine.
A few exeptions to this rule are:
- Space qualified pointers
When you want to specify both which space a pointer is pointing to AND in which space it is located, Keil's syntax is somewhat different from what ANSI says. Raisonance's syntax is closer to the standard.
Consider the following example, where you want to declare a pointer to a char in code memory, and the pointer has to be in data:
For Raisonance you would write
char code * data ptr;
while with Keil you would write
data char code * ptr;
A way to write a code that is correctly compiled by both compilers is to use typedef as follows:
typedef char code *tcptr2code;
data tcptr2code ptr;
For more information on how to define space-qualified pointers click here
- Signed and unsigned char
Char is signed by defalult in Keil. You can manually declare an unsigned char in the c source file by using the syntax
unsigned char x;
Char can be by default signed or unsigned in Raisonance depending on the option "Unsigned Characters" in Options|Project|RC51|Code Generation. The default value for this option is Unsigned Chars.
Note also that, with Raisonance declaring
unsigned char x;
or
char unsigned x;
is the same, while in Keil the second syntax is not accepted.

^RC-51compiler FAQs   ^top

 Q: Is there something special to do to use memory allocation functions with RC51 ?
A: Using memory allocation functions such as malloc() with RC51 requires to initialize the 'memory pool' first by using the mempool_init function.
The following code provides an example of a basic usage of malloc and mempool_init.
*******************************************************************
#include "alloc.h"
#include "stdio.h"
#include "string.h"
// Specify where the buffers will be allocated.
xdata unsigned char mempool_buffer[0x100];
char* buffer;
void main( void )
{
// Initialization of the memory pool
mempool_init( mempool_buffer, sizeof( mempool_buffer ) );
// Allocates a 40 bytes buffer
buffer = (char *)malloc( 40 );
if( buffer != NULL )
{
// Writes something in the buffer and then print it
strcpy( buffer, "hello" );
printf( "40 chars Buffer = %p, %s \n", buffer, buffer );
}
else
{
printf( "print buffer error %p \n", buffer );
}
while(1);
}

^RC-51compiler FAQs   ^top

 Q: Sometimes the result of an additon or multiplication is wrong: why ?
A: The first possibility is that the variable where the result of the operation it to be stored is not big enough to contain it (char can contain up to 255, int up to 65535 etc).
Another, more subtle, possibility is that the operands are of a smaller type than the result and that the 'Enable ANSI integer promotion rules is not checked': click here for an example.

^RC-51compiler FAQs   ^top

 Q: I try to call a function, but the function is never reached. The compiler does not generate any code for my function call. Why?
A: It's probably a matter of missing parenthesis ().
Consider the following example:
void init_eeprom(void)
{
}
void main(void)
{
init_eeprom(); // This is correct
init_eeprom; // This will not generate any code
}
Note that the wrong syntax without () will not produce any error or warning.

^RC-51compiler FAQs   ^top

 Q: When I use the compiler from the command line (or from a makefile), a huge .lst file is generated with every line number. How can I avoid this ?
A: This is a feature that is very useful when working in DOS 'on the screen', but it becomes unpractical when the output is redirected to a file, for example when using an external makefile.
To tell the compiler not to print too many lines use the QUIET option in the command line like in the following example:
RC51.exe C:\Ride\Examples\C\towers\towers.c LARGE QUIET

^RC-51compiler FAQs   ^top

 Q: How do I use the full 1kb of internal RAM available on some 8051 derivatives like the 89C51RD+ ?
A: Some 8051 derivatives, like the 89C51RD+, have 1Kbyte of internal RAM. However, only the first 256 bytes of this memory can be addressed as DATA/IDATA, while the rest must be accessed using the MOVX instruction, exactly as if this extra RAM was outside of the chip.
To use the full 1K you should therefore either declare some of your variables to be in XDATA or to use a memory model where variables are put in XDATA memory by default (COMPACT, LARGE and HUGE models).
You should also make sure that you application clears the EXTRAM bit (bit 1 of AUXR1), by doing this explicitly at the beginning of the code or by modifying the startup code.

^RC-51compiler FAQs   ^top

 Q: What does the startup code do? Do I need it? How can I modify it?
A: This note will tell you everything there is to know about 8051 startup code for Raisonance tools.
What is the startup code?
From the RC51 manual:
The Startup Code contains initializations needed to make your C program work correctly. It is executed at power-up and, when finished, it jumps to the “main” function of your application. An appropriate version of the startup code (depending on some parameters like memory model and others) is linked with the rest of the application when the “main” symbol is found by the compiler and performs a variety of initialization tasks including:

  • Initialize the internal memory to 0
  • Initialize Static variables, as required by ANSI
  • Initialize the timer0 to obtain a UART frequency of 9600 with typical quartz.
  • Initialize the stack pointer

The Startup Code is written in assembler and can be found in the file ride\inc\sources\8051\rc51\startup.a51. It is recommended not to modify this file; if you need a specific initialization for your project we suggest you perform it at the beginning of the “main” function.
Do I need it?
If you are programming in C you definitely need the startup code in 99% of the cases (there could be exceptions, for example for modules that are not executed at power up, but rather called by other modules)
The standard startup code is included by the linker when the main() symbol is found (therefore, an easy way to avoid the startup code is to write a program without main() function), and works well for most cases (different chips, different HW configurations, different tools options), but, in some cases, you might want to extend or modify the startup code as explained below.
How is the startup code managed in RIDE?
Starting around BN729 (second half of 2002), RIDE offers 3 different possibilities to manage the startup code, as shown in the picture below (note that the Starup Opions are part of the Linker options, even if there is also 1 option in the compiler that can affet startup code)

The "Default Startup" Option

The default option is "Default Startup". When you check this option, the linker will do the following:

  • Look in the libraries for the correct startup file (which is determined by a number of parameters, including the memory model, the source code, the derivative chosen and the debug target)
  • Replace some constant values that are in the object file with the value of fields like "Initialized RAM size" and "Initial Value for Timer 1"
  • Link the resulting object with the rest of your application, without leaving any trace in the project tree (the only way to check that the initialization code has actually been included is to check the map report from the linker, where you will find a segment called ?PR?C51_STARTUP?)

This approach is the safest and is also pretty well optimized, but, in some cases, you might need extended startup functionality: in this case you can use one of the two options below.

The "User Defined Startup" Option

Use this option when the startup code you need is totally different from what is provided by default with RIDE. When you use this option, the linker will simply not include any startup code (exactly the same as if your application contains no main() function): it's up to you to manually add a node in the project tree that contains some startup code. Note that, if you just take whatever C program and try out this option without adding a properly working startup code of your own, you will not even be able to start the debug session, as there will be no reset vector (a random part of your code will be put at address 0 and the stack will not be initialized behavior).
If you program in C, your specific startup code will need to do most of the things that are done by the standard startup anyway, so we suggest you use the method described below instead, but this option is left for cases where no startup altogther is needed (for example, as already mentioned, to compile a set of routines that will be launched by some other program)

The "Micro-Specific Startup" Option

Use this option when the startup code you need is basically the standard one, plus some micro-specific initialization (typically for HW features, such as buses, configuration bytes or peripherals).
When you use this option, RIDE will do the following:

  • Take the standard startup file that is under RIDE\INC\SOURCES\8051\RC51\startup.a51 (you can see the version as of BN730 here)
    Take the code that you have entered in the "Micro-specific Initialization code" text field (note that this field is pre-filled with the appropriate code for some derivatives) and insert it in the startup.a51 file (between markers; it's line 201 in the file linked above)
    Create a new file called startup.a51 in the project directory and insert a new node in the project for this file (after asking confirmation)

You can now customize the startup file that is in the project tree by edtiting it (be careful to follow the guidelines provided in the comments).
Note that, some of the startup customizations that are done via the RIDE interface (example: Initialized RAM size) or automatically (example: way used to address >256 bytes of XDATA) are not taken into account here: you need to do everything manually by editing the startup.a51 file.

Micro dependencies: initialized Xdata variables of more than 256 bytes.

The startup code is usually not too much dependent on the particular 8051 derivative choosen, in what most of the micro specific features (usually peripherals) can be initialized in the main application, but there are some exceptions to this rule, including some SFRs initialization that must be done before accessing memory (example of the uPSD, this is managed by RIDE by automatically prefilling the "Micro-specific Initialization code" field) and accessing XDATA variables over the first 256 bytes.
Note first that the startup code only needs to access XDATA over 256 bytes if you have more than 256 bytes of initialized XDATA variables in your application: this is quite rare, but in case it happens you need to read the following.
Different 8051 derivatives implement different ways of accessing XDATA memory over 256 bytes: typically this is accomplished by using P2 as the high byte of the address, but some derivatives (especially those with internal XRAM) use different SFRs for this. The startup code is written to be as compact as possible, and will therefore try to intialize the XRAM memory using the MOVX @Ri instruction, but this does not work over 256 bytes when P2 is not used: in this last case the XRAM must be initialized using the MOVX @DPTR instruction.
When using the "Default Startup" option, the linker will choose which addressing mode to use according to the value of the option "Component with XRAM" shown below.

When using the "Micro-Specific Startup" option, you must edit the startup file if you need to initialize XDATA variable >256 bytes (look for INTERNAL_XRAM_LIKE_8xC592 in the startup.a51).

^RC-51compiler FAQs   ^top

Q: How can I make several interrupt vectors execute the same interrupt routine ?
A: When declaring a function as an interrupt routine, you can use the special interrupt syntax:
  void my_isr () interrupt 1
    {
    ...
    }
Unfortunately, several interrupt declarations for the same function are not allowed. A workaround for this is to write a macro to define each interrupt vector assembly code manually:
  void my_isr () interrupt 1
    {
    ...
    }
  typedef struct sIRQ_Vector {
    char ToBeLJMP;                //to be initialized with 0x02
    void (*func) ( void );        // address of the function ended by RETI
  } tIRQ_Vector;
  #define VECT_TO_FCT(ref, func) at (8*(ref)+3) code tIRQ_Vector Vect_for_irq_##ref = { 0x02, func};
  VECT_TO_FCT(4, my_isr)
  VECT_TO_FCT(5, my_isr)
  VECT_TO_FCT(6, my_isr)

^RC-51compiler FAQs   ^top

 

8051

MA-51 macro assembler

 

Q: How can I manage public and external symbols in my project?
A: The PUBLIC and EXTERNAL assembler directives allow to share symbols (variable names, labels etc) between different assembler files.

  • Definition of a PUBLIC Symbol:
    Every time you have a symbol that you want to use outside the file where is it declared you must define it as PUBLIC using the following syntax : PUBLIC MySymbol
  • Definition of an EXTERNAL Symbol:
    Every time you want to use a symbol that has been declared in a different source file (Assembler or C) you must define it as EXTERNAL using the following syntax : EXTERN memspace (MySymbol)
    where memspace is the memory space of the segment where the symbol has been defined as public (choose among DATA, IDATA, XDATA, CODE, BIT, ...).
    Note that every symbol declared as EXTERNAL must have been declared as PUBLIC in another module.
^MA-51 FAQs       ^top
 

Q: Which other assembler syntaxes are accepted by the Raisonance MA51?
A: Raisonance's MA51 accepts both the ASM-51 syntax from INTEL and the A51 syntax from Keil.

^MA-51 FAQs       ^top

Q: The assembler seems to translate only part of my source file. What is wrong ?
A: MA51 creates only one object file for one source file. If you have assembly code in your source file plus several include files, it will always translate the last source file and ignore the other source files. Therefore, if you put e.g. an include file at the end of your source file, it will translate the include file, whereas it will translate the assembly source file if you put the include files at the beginning.

So how are all included files plus the source file translated?

  1. The first solution is to specify that you want an object file with an extended format. To do that select 'Extended (OE)' in the box 'Debugging information' under the RIDE menu 'Options | Project | MA51 | Object'. In this case, all the assembly code is in the object file.
  2. The second solution is the preferred one in terms of project organization: it is to insert the include files in the project and not in the main file. In this case, all source files will have an object file. Do not forget to declare in your original source file the external functions with the keyword "extrn", and in the original include file with "public".
^MA-51 FAQs       ^top

Q: I Try to call a C function from assembly code, but a syntax error appears: what can I do?
A: The best is to write an equivalent C program, and to generate the SRC (select the SRC mode in "Options|Project|RC51|Object").

^MA-51 FAQs       ^top

8051

RL-51 linker

Q: When linking my project I obtain a message error 107 'ADDRESS SPACE OVERFLOW - Segment: ?C_XSTACK': Why?

A: This segment contains the external stack and all the 'pdata' qualified variables. This segment is limited up to 256 bytes in external RAM (xdata). Therefore you must check that the size of 'pdata' variables plus the external stack size (if you are using it) is less than 256 bytes.

^RL-51linker FAQs   ^top

Q: Our microcontroller has 20 Kbytes internal code memory, 256 bytes RAM. My problem is that I have an error message when linking: ERROR 107: ADDRESS SPACE OVERFLOW - SEGMENT: ?DT?...
I do not understand this, because my total program code is only xxx bytes, so I still have free code memory. What is going wrong?

A: The address space overflow occurs on a DATA segment (?DT?...). You have more than 128 bytes of direct addressable variables or more than 256 bytes of indirect addressable variables. There are several solutions:

  1. If you are using the SMALL memory model for the RC-51, try the LARGE memory model if your board has external data memory. This puts the variables in xdata space by default.
  2. Otherwise try to decrease the number of variables addressable in Data space.
  3. You can use a space qualified variable definition in idata memory space such as 'char idata var_name;' to define a variable in a specific memory space.
  4. Can you put all your constant variables in code space?

Q: What does the linker error 121 'IMPROPER FIXUP' mean?

A: It means that a reference cannot be resolved by the linker.

  • In most cases, this error occurs when an AJMP (ACALL) to an external symbol cannot be reached because the symbol is farther away than 2Kbytes. The solution is to convert the AJMP or ACALL into a LJMP or LCALL.
    This can typically happen when you program in assembler, but can also happen when programming in C in the TINY memory model.
  • The same message can be output for a SJMP NOT_REACHABLE_SYMBOL and may occur when a bit of a bdata byte is accessed that will not be relocated into BDATA (bit addressable space).

^RL-51linker FAQs   ^top

Q: Where is the stack located in my project?
A:

  • The internal stack: exact location is in the Map Report of the LX51 linker (accessible via menu 'View | Map Report from Linker').
    In this file, you find the details about ' DATA MEMORY '.
    At the end of this section, you encounter a segment _STACK with the relocation "STACK".
    On this line you have first the physical memory space 'TYPE' (DATA or IDATA), then the absolute base address (under 'BASE'), and always a length 'LENGTH' of 1.
    In fact the length is limited to the amount of internal memory in your microcontroller. In the start-up routine of your program, SP is initialized to this absolute base address.
  • The external stack is always located at the beginning of a 256 byte 'page' of XDATA memory (if your application uses this feature, selected in the RC-51 compiler options 'Options | Project | RC51 | Memory Model | Use External Stack') :
    The segment name 'SEGMENT NAME' for this stack is '?C_XSTACK".
    So to find it you have to locate the details of  "XDATA MEMORY.
    At any time, this 256 byte 'page' of XDATA is pointed to by P2.
    SPX is a DATA MEMORY byte reserved by the compiler and managed as SP in the internal memory for the internal stack.

^RL-51linker FAQs   ^top

Q: How can I occupy fixed positions in memory?
A: For a variable declaration, use the keyword AT to specify the position in data space, e.g.:

  1. AT 0x500 data char variable_name;
  2. If you have to put more variables at fixed positions, in the same context, maybe it is better to use a structure:
    AT 0x500 structname struct {
    int variable1;
    int variable 2;
    char variable2;
    };
  3. If you want to have direct access to a specific memory location, use a pointer:
    *(char xdata *) (0x500) = 10;
  4. If you want to know exactly where the variables of a whole file are in memory, do the following:
    Via 'Options | Project | Lx51 | More' put: 'xdata(?xd?filename(0x1000))'. Then, all the relocateable variables in the filename will be positioned after the address 0x1000 in the xdata space.

^RL-51linker FAQs   ^top

Q: How do I relocate some functions to an absolute address?
A: Relocating ONE function is easy (using the "at" attribute in the source).
Relocating ALL functions is still easy, using the FRelocation fields under Options|Project|Linker|Relocation.
Relocating a set of functions however is tricky and requires using the "more" field under Options|Project|Linker with a syntax that you can see in the picture. Note that you must take the module/function names from the map file (View|Map report from the linker), because they are different from what you call the same function in your source, and that those names might change if you change important parameters for the fucntion (example reentrant/not reentrant).

^RL-51linker FAQs   ^top

Q: What does the startup code do? Do I need it? How can I modify it?
A: This note will tell you everything there is to know about 8051 startup code for Raisonance tools.

What is the startup code?

From the RC51 manual: The Startup Code contains initializations needed to make your C program work correctly. It is executed at power-up and, when finished, it jumps to the “main” function of your application. An appropriate version of the startup code (depending on some parameters like memory model and others) is linked with the rest of the application when the “main” symbol is found by the compiler and performs a variety of initialization tasks including:

  • Initialize the internal memory to 0
  • Initialize Static variables, as required by ANSI
  • Initialize the timer0 to obtain a UART frequency of 9600 with typical quartz.
  • Initialize the stack pointer

The Startup Code is written in assembler and can be found in the file ride\inc\sources\8051\rc51\startup.a51. It is recommended not to modify this file; if you need a specific initialization for your project we suggest you perform it at the beginning of the “main” function.

Do I need it?

If you are programming in C you definitely need the startup code in 99% of the cases (there could be exceptions, for example for modules that are not executed at power up, but rather called by other modules)
The standard startup code is included by the linker when the main() symbol is found (therefore, an easy way to avoid the startup code is to write a program without main() function), and works well for most cases (different chips, different HW configurations, different tools options), but, in some cases, you might want to extend or modify the startup code as explained below.

How is the startup code managed in Ride7?

Starting around BN729 (second half of 2002), Ride7 offers 3 different possibilities to manage the startup code,  (note that the Startup Options are part of the Linker options, even if there is also 1 option in the compiler that can affect startup code).

"Default Startup" Option: The default option is "Default Startup" (shown in the picture above). When you check this option, the linker will do the following:

  • Look in the libraries for the correct startup file (which is determined by a number of parameters, including the memory model, the source code, the derivative chosen and the debug target)
  • Replace some constant values that are in the object file with the value of fields like "Initialized RAM size" and "Initial Value for Timer 1"
  • Link the resulting object with the rest of your application, without leaving any trace in the project tree (the only way to check that the initialization code has actually been included is to check the map report from the linker, where you will find a segment called ?PR?C51_STARTUP?)

This approach is the safest and is also pretty well optimized, but, in some cases, you might need extended startup functionality: in this case you can use one of the two options below.

"User Defined Startup" option: Use this option when the startup code you need is totally different from what is provided by default with Ride7. When you use this option, the linker will simply not include any startup code (exactly the same as if your application contains no main() function): it's up to you to manually add a node in the project tree that contains some startup code. Note that, if you just take whatever C program and try out this option without adding a properly working startup code of your own, you will not even be able to start the debug session, as there will be no reset vector (a random part of your code will be put at address 0 and the stack will not be initialized behavior).
If you program in C, your specific startup code will need to do most of the things that are done by the standard startup anyway, so we suggest you use the method described below instead, but this option is left for cases where no startup altogther is needed (for example, as already mentioned, to compile a set of routines that will be launched by some other program)

"Micro-Specific Startup" option: Use this option when the startup code you need is basically the standard one, plus some micro-specific initialization (typically for HW features, such as buses, configuration bytes or peripherals). When you use this option, Ride7 will do the following:

  • Take the standard startup file that is under RIDE\INC\SOURCES\8051\RC51\startup.a51 (you can see the version as of BN730 here)
  • Take the code that you have entered in the "Micro-specific Initialization code" text field (note that this field is pre-filled with the appropriate code for some derivatives) and insert it in the startup.a51 file (between markers; it's line 201 in the file linked above)
  • Create a new file called startup.a51 in the project directory and insert a new node in the project for this file (after asking confirmation)
  • You can now customize the startup file that is in the project tree by editing it (be careful to follow the guidelines provided in the comments).

Note that, some of the startup customizations that are done via the Ride7 interface (example: Initialized RAM size) or automatically (example: way used to address >256 bytes of XDATA) are not taken into account here: you need to do everything manually by editing the startup.a51 file.

Micro dependencies: initialized Xdata variables of more than 256 bytes.

The startup code is usually not too dependent on the particular 8051 derivative choosen, in that most of the micro specific features (usually peripherals) can be initialized in the main application, but there are some exceptions to this rule, including some SFRs initialization that must be done before accessing memory (example of the uPSD, this is managed by Ride7 by automatically prefilling the "Micro-specific Initialization code" field) and accessing XDATA variables over the first 256 bytes.
Note first that the startup code only needs to access XDATA over 256 bytes if you have more than 256 bytes of initialized XDATA variables in your application: this is quite rare, but in case it happens you need to read the following.
Different 8051 derivatives implement different ways of accessing XDATA memory over 256 bytes: typically this is accomplished by using P2 as the high byte of the address, but some derivatives (especially those with internal XRAM) use different SFRs for this. The startup code is written to be as compact as possible, and will therefore try to intialize the XRAM memory using the MOVX @Ri instruction, but this does not work over 256 bytes when P2 is not used: in this last case the XRAM must be initialized using the MOVX @DPTR instruction.

When using the "Default Startup" option, the linker chooses which addressing mode to use according to the value of the option "Component with XRAM".

When using the "Micro-Specific Startup" option, you must edit the startup file if you need to initialize the XDATA variable >256 bytes (look for INTERNAL_XRAM_LIKE_8xC592 in the startup.a51).

^RL-51linker FAQs   ^top

  

8051

TI MSCxx development board

 

Q: How can I use TI's downloader together with Ride7?

A: TI's downloader is a piece of software provided by TI with the MSC evaluation board, that allows you to load a hex file into the memory of the MSC chip that is on the board, and then execute it without any debug functionality.
In the first steps of your application you usually don't need the downloader: when you start a debug session with Ride7, and the MSC board is selected as the debug target (picture below), Ride7 automatically downloads your application to the board (+ everything needed for debug, typically the ROM monitor).

The downloader is typically useful when your debugging is nearly finished and you want to run your "real" application, without the control of (and any interference from) Ride7.

The TI downloader can be configured to work in conjunction with Ride7 in 3 different ways:

  1. As a separate tool, that can be invoked using the Tool|Run Tool.. menu
  2. The downloader is automatically invoked after the linker (last picture)
  3. The downloader is selected as the debug tool and is executed when you start the debugger (picture below)

Note that, as the only purpose of the downloder is to download your application to the board without any debugging functionality, once the download is done, all you have to do is reset the board and see if it works as you expect. In view of this, the three ways of using the downloader presented above are largely equivalent, apart that, for the first and the last, you have to take action to execute the downloader, while the second way executes it automatically (but that also means that it may execute it when you don't want it to, thus wasting time and shortening the life of the onchip Flash memory).

Whichever way you want to use the downloader, you must first install it using TI's installation program and then configure the downloader as a Ride7 external tool: this configuration is typically needed only once (if you check the "register for the application" button as explained below).

To configure the downloader follow these steps:

  1. In Ride7, select Option|Tools and then New. A window like the one in the picture below will appear
  2. Fill in the fields as shown in the picture (you can chamge the "Name" if you want to)
  3. Don't forget to check the "register for the application" button, or you will need to repeat these steps for every new project
  4. Click on "advanced options", the window below will appear
  5. If you want the downloader to automatically take the project you are working on and typical parameters for the com port and clock frequency, copy the content of the "Arguments" field shown in the picture
  6. Check the box "Prompt before running" if you want to see a message before the downloader is executed

Now the loader is configured. You can manually call it any time using the Tools|Run Tool.. menu, or by selecting it as the debug target and then starting the debugger. If you want the loader to be executed automatically after the linker, proceed as follows:

  1. In the project window, right click on the project line (the first line in the window) and select Node Properties; the window below will appear
  2. Check the "Post Link" box and select the TI downloader as the tool to be executed automatically after link

Note that, if you follow this procedure and then go back to normal debugging using Ride7 without unchecking the button, the application will be loaded twice for every debug session (once by the loader, the other by Ride7): this is a waste of time and risks to shorten the life of the flash memory inside the device.

Notes on using the ROM monitor to debug with TI EVM and DAQ boards

Generally speaking, a ROM monitor is a piece of code that allows (limited) debugging of the application loaded on the EVM or DAQ board.
In the case of these specific boards, most of the ROM monitor is already on the board (stored in the non volatile memory of the chip); Raisonance tools will only add to your application a few functions that are needed to link with this monitor.
Two things to keep in mind when using this ROM monitor;

  1. The ROM monitor can use a special function of the chip, called hardware breakpoints.
  2. In some conditions (Software Breakpoints, slow baudrate), the ROM monitor can be VERY slow (up to 1 minute for a single step).
^TI FAQs       ^top

Q: What to pay attention to when using interrupts already used by the ROM monitor?
A: If your application uses some interrupts already used by the ROM monitor, you have to pay attention to two points:

  1. See section 2.3.2 "Modify interrupt vectors"in the complete ROM monitor documentation.
  2. Look at the specific question on the Forum Support.
^TI FAQs       ^top

Q: After programming our MSC1210 (EVM Board from TI) with the included emulator, we cannot access the Boot ROM routines. In simulation mode everything works fine.
A: When using the emulation mode, do NOT call the autobaud routine.
Ride7 modifies the executable to execute an autobaud at reset. Therefore, your "autobaud" call could break the monitor state.
However, you can call the other (programming) functions.

^TI FAQs       ^top

8051

KR-51 real-time kerneI

Overview of the scheduler operation


Q: How does the scheduler work ? It appears that some tasks never gets executed, why ?
A: You might expect that, when you create a simple application with two tasks of the same priority, the scheduler will automatically manage to execute both alternatively, but this is not the case: because the KR scheduler is specific for real time applications, each task must take the initiative to 'give the CPU up' to other tasks, by putting itself in a state that causes the scheduler to reschedule the tasks (for example by calling a timeout, or by entering in a wait state for a signal or for a resource - see the documentation for the detailed list).
Note that, because the main() of your program is like a task of the lowest possible priority, if you create your tasks in the main and the first task you create never gives up the cpu, the other tasks (whatever their priority with respect to the first created), never get created at all.

 

^KR-51 FAQs       ^top

8051

PLM51

Debugging applications containing PLM51 source code

 

Q: Can I debug applications including PLM/51 source code with Ride7 ?
A: Yes. For this Ride7 needs an absolute object file (OE format) of the PLM modules. Raisonance has developed a converter which converts the standard object file (in OMF-51 format produced by the PLM51 compiler) to the OE format. From Ride7, you should create a tool that invokes an MS-DOS batch file (see picture).

The batch file should look like the following:
plm51 program.p51 DB
omf2oe.exe program.obj lst(program.lst)
copy program.obj program.ob1
copy program.out program.obj

The PLM51 object node of the project is associated with the tool created above.
In the debugger, the source debugging process of PLM51 modules will be done with the .LST file.

^PLM51 FAQs       ^top

 

8051

XEVA development board

Q: Is it possible to use DISCOVERKIT-51 or RACK-51 under MS-DOS or Windows 3.1X?
A:

  • Under Windows 3.1X : The ROM monitor is only available with Ride7 (which runs under 32-bit Windows). Under Windows 3.1X, you can only use the downloading facilities (with Terminal.exe). No debugging facilities are available.
  • Under MS-DOS : You can only use the downloading facilities (with a MS-DOS terminal software or the MS-DOS copy command). No debugging facilities are available.

Q: Can I use P0 and P2 of the microcontroller as I/O ports with the XEVA board ?
A: The XEVA evaluation board is a ROM-less mode target. The P0 and P2 are address/data buses to access the external EPROM and RAM.

In the downloading mode (with a terminal) and monitoring mode (with MONITOR-51), it is not possible to use P0 and P2 as I/O for your application.

For an industrial application purpose (OEM), you can use P0 and P2 as I/O ports. In this case :

  • Put an embedded 8051 as the microcontroller on XEVA (87Cxx).
  • The application program will be burned into the embedded microcontroller.
  • Remove the straps from OC and EA selections on the XEVA board.
  • Remove all peripherals which are SRAM or EPROM and which are connected to the P0 and P2 bus.

In this mode, no downloading or debugging facilities are available.

Q: Is it possible to use INT0 and INT1 in my application with XEVA ?
A:

  • When you use XEVA alone or XEVA with XEVA-DEMO V1, without the external UART, there are no restrictions on using INT0 and INT1 in your application.
  • When you use XEVA in the DISCOVERKIT-51 or RACK-51 set, with the external UART, INT0 is used for the ROM-Monitor (standard settings). Only INT1 is available for your application.

Q: (DISCOVERKIT-51, XEVA, RACK-51) With XEVA, can I use the internal UART of the 8051 derivative for my own application ?
A: When you use an XEVA with a 8051 derivative alone, you do not have any external UART for downloading the code or monitoring. You have to use the internal UART.

If you use an XEVA with a Terminal or Hyper-terminal (you download your application code), you can use the internal UART for your application, after the GO command.

If you use an XEVA controlled from Ride7 with the monitor option active, you cannot use the internal UART for your own application as the monitor always communicates with the PC during all debugging processes.

In order to free the internal UART, the XEVA-DEMO V2 board has been developed, which includes an external UART. This board is supplied with the DISCOVERKIT-51 set.

Q: I cannot communicate with the XEVA board (through the terminal or the Windows integrated ROM-Monitor). What can be the reason?

A: The reasons for a communication error can be multiple:

  • Verify the hardware configuration of XEVA, DISCOVERKIT-51 or RACK-51
  • Verify your Personal Computer serial port cofiguration
  • Verify the Ride7 software configuration ('Options | Project' and 'Options | Debug').

Attention! : Before starting a debugging session, please reset your hardware (XEVA or RACK-51).

Q: (XEVA, DISCOVERKIT-51, RACK-51) When using MONITOR-51 with the XEVA evaluation board, what are the restrictions ?
A: The MONITOR-51 includes libraries which are linked with your application. The MONITOR-51 functions manage the XEVA board, under the Windows Ride7 and allow debugging facilities like breakpoints, step-by-step, etc...
These libraries are relocated by the linker, and need some resources in order to work, in the CODE, XDATA, DATA and SFR spaces of the microcontroller.

Restrictions :

  • Code space : The MONITOR-51 needs about 5 Kbytes in the code space. This code is relocatable, except for 6 bytes from 0000h to 0005h that are reserved for the monitor.
  • Xdata space : About 900 bytes are used for monitoring. These variables are relocatable.
  • Data space : The monitor permanently needs 10 bytes for the stack. Consequently an application program may use only 128 (or 256) minus 10 bytes of data space.
  • SFR and BIT space : Communication with the external UART : Some SFRs are used for monitoring and should not be altered : INT0, the IT0 and IE0 bits of the TCON SFR, the EA, ET0 and EX0 of the IE SFR and the PX0 bit of the IP SFR.
  • Communication with the internal UART UART0 : SBUF, SCON, PCON, TMOD, ES and PS should not be altered.
  • During a debugging session, the application program must not alter the CODE, DATA, XDATA and SFR sections used by the monitor.
    Any alteration could generate a fatal error ("The communication has been lost").

Q: (DISCOVERKIT-51, XEVA, RACK-51) How can I replace the TELEXEVA EPROM of an XEVA with my own application program ?
A: To replace the TELEXEVA EPROM with your own code, you have to:

  1. Remove the TELEXEVA EPROM from its socket.
  2. Remove the SW3 strap
  3. Configure the SW2 strap for a 27C256 (SW2 OFF) or for a 27C512 (SW2 ON).
  4. Program your EPROM (see the FAQ 'GEN: Generating the .bin or .hex file of the application.')
  5. Insert your application EPROM (27C256 or 27C512) into the XEVA Eprom socket.

Your application is then ready to run.

Q: (XEVA DISCOVERKIT-51) What is the standard configuration for XEVA with TELEXEVA V3.00 ?
A: TELEXEVA V3.00 has been developed for the new XEVA-DEMO V2 board that includes an external UART.

The standard configuration of XEVA without XEVA-DEMO V2 is:

  • Communication on UART0 (via connector SER1)
  • Code space : 0-FFFFh
  • XDATA space : 0-FFFFh
  • Strap on : RX1,RX2,OC,EA,VEXT,SW3,SW4
  • Strap off : SW1,SW2,SW5,PE

The standard configuration of XEVA with XEVA-DEMO V2 (DISCOVERKIT-51) is:

  • Communication on external UART (via connector SER2)
  • Code space : 0-7FFFh
  • XDATA space : 0-7FFFh
  • Strap on : RX1,RX2,OC,EA,VEXT,SW3
  • Strap off : SW1,SW2,SW4,SW5,PE

Q: (XEVA, DISCOVERKIT-51, RACK-51) What is the standard configuration of XEVA with TELEXEVA V3.02 ?
A: TELEXEVA V3.02 has been developed for the RACK-51 set and is also supplied with XEVA and DISCOVERKIT-51 sets.
New V3.02 features are:

  • Accepts 8051 derivatives from 80C32 (does not support 80C31).
  • Code space : 0-7FFFh (with SW1 OFF), 0-DFFFh (with SW1 ON).
  • XDATA space : 0-7FFFh (SW4 must be OFF).
  • The SW3 strap selects the ROM-Monitor peripherals (useful for RACK-51).
  • The configuration is presented on the XEVA-DEMO LCD display.

Q: What are the revisions of the TELEXEVA EPROM of the XEVA board ?
A: The revisions of TELEXEVA software concern both the EPROM and the PLD in the XEVA board.

TELEXEVA V1.00 : First stage of TELEXEVA : includes a down-loading program for Terminal and Hyper-terminal. Does not include facilities for MONITOR-51.
TELEXEVA V2.1 : Includes 8051, 8051-XA and 80C251 down-loading and MONITOR-51/XA/251 facilities.
TELEXEVA V3.00 : Release of V2.1. Includes management of the External UART for communication.
TELEXEVA V3.02 : Includes new selection of peripheral addresses useful for the RACK-51 set.
Upon request you may obtain a copy of TELEXEVA V3.00 free.

Q: Does the XEVA support 80C51XA derivatives ?
A: The high speed version of the XEVA called XEVA-FAST, supports some 80C51XA derivatives with special adapters :

  • with XV-XAG3 : supports the 8051-XAG3 in ROM-less 8-bit mode.
  • with XV-XAS3 : supports the 8051-XAS3 in ROM-less 8-bit mode.

The DISCOVERKIT-XA set allows development of XA applications with the XEVA-FAST board and includes an integrated ROM-Monitor.

The new XA-C3 is not supported because it does not allow 8-bit mode for the address bus. It will be supported in the future with the XEVA-16 board (16-bit evaluation board).

 

8051

CodeCompressor

 

 

Q: Why CodeCompressor? Can't you just optimize the compiler better?
A: CodeCompressor does something the compiler cannot do, because it has an overall view of the application (C code, Assembler code, libraries and whatever else might be included) that the compiler cannot have because it works on one source file at a time.
That's why CodeCompressor always reduces the code size, even when used with a highly optimizing compiler.
Note that most of the compression techniques used by CodeCompressor are already used by the compiler (example: factorization): it's just that the scope of the optimization is different. 

Q: How do I start the CodeCompressor ?
A: CodeCompressor is started by clicking on the compressor icon in the icons bar. For CodeCompressor to work properly make sure that the 'Generate PostOptimizing information' box is checked in Project ¦ Target.

Q: How do I use CodeCompressor in Interactive mode ?
A: To use CodeCompressor in interactive mode you must check the 'Interactive' box in Options¦Project¦CodeCompressor¦General.

Once this box is checked, when you click on the compressor icon, CodeCompressor is started in an interactive mode: a CodeCompressor window is automatically displayed that guides you through the possible optimizations.

Note that once optimizations have been performed, you will debug the optimized code: this means you will have reduced features for single step and variable watch/inspection, because some debug information is lost in the compression process.

Q: How do I use CodeCompressor in Automatic mode ?
A: To use CodeCompressor in automatic mode you must check the 'Automatic' box in Options¦Project¦CodeCompressor¦General. In the same menu you must choose which of the possible optimizations you want to perform (usually all of them, to get the best compression).

Once this box is checked, when you click on the compressor icon, your project is rebuilt and compressed according to the options you selected. The result of the compression is saved as project_name_CC in .aof/.bin/.hex format according to the options you selected in Options¦Project¦CodeCompressor¦Save.

Note that, when you start debugging, the uncompressed version of the project is loaded: this is because the compressed version has limited debug information in it and therefore is not intended for debug. If, for any reason, you want to debug the compressed version directly, you should use the Interactive mode.

Q: Does a demo version of CodeCompressor exist? What are its limitations?
A: A demo version of CodeCompressor is included with the demo version of 8051 development tools available for free download at www.raisonance.com.
CodeCompressor is limited in that you can compress the code but you can't save it.

Q: Is it possible to use CodeCompressor with the Keil compiler/other 8051 compilers?
A: No. CodeCompressor needs special information to work (example: distinction between code and constants) that is generated only by the Raisonance toolchain.
Note however, that, because the Raisonance compiler is compatible with C51 it is quite easy to recompile existing sources with the Raisonance toolchain and to compress them afterwards.
__________________________________________________________________________________________________

Q: My application is sligthly bigger than 64 Kb: can I compress it and see if it becomes <64Kb ?
A: You need a workaround here, because, if the application is >64Kb, the linker will generate an error and will not allow you to run CodeCompressor.
The workaround is as follows:

  • Reduce temporarily the size of one of the modules, in such a way that it has as little impact as possible on the overall application (for example, if you have big tables in code memory, reduce their size)
  • Run CodeCompressor on the applications, which is now <64Kb and will become even smaller after CodeCompressor
  • Re-include the original version of the module you have artificially downsized, directly in HEX, and see if the overall application now fits in 64K.

This procedure is quite complex, but it is, at present, the only way to compress a program from >64K to <64K.

Q: I get the "Undefined Blocks" error and CodeCompressor does not work. Why?
A: "Undefined Blocks" means that the CodeCompressor is missing some important information about the code to be compressed and therefore cannot do its work.
Possible causes are:

  • You didn't check the "Genarate Post Optimization Information" box in Options|target
  • You are using a path for libraries that is different from the standard one and that does not contain a sub-directory called CcLib with the CodeCompressor-specific libraries: in this case CodeCompressor automatically tries to use the default libraries, but they don't contain the Post Optimization information, hence the error. Either copy the ride/lib/cclib directory under your own or put your libraries in the default directory.

8051

PCE5130C/40C emulators

 

Q: Can I emulate Atmel microcontrollers with PCE-5130C and RPD-HK500 ?
A: The answer depends on the application and the microcontroller:

  1. If your application uses P0 and P2 as Address/ Data bus (ROM-less emulation mode), the answer is YES. You just need to put the Atmel MPU to be emulated into the ADP-HKxxx adapter, and select the 'Others' configuration with 'Options | Debug | Advanced Options | Config | Others' in Ride7.
    In 'Advanced Options' make sure you have 'Real Machine' and 'PCE-5130C' selected.
    In 'Config' have 'RPD-HK500' selected.
  2. If your application uses P0 or P2 as I/O, one question is important: Is the Atmel MPU to be emulated fully compatible with an 80C52 ?
    a) If yes, you will be able to emulate the MPU as an 80C52 with the standard Siemens emulation MPU.
    b) If not, you will not be able to emulate completely this MPU.
    c) For an AT89C1051/2051 and 4051, the answer is yes, with the ADP-2051DP adapter, and with the RPD-HK500/ADP-HK501 pod.
^PCE FAQs       ^top

Q: Can I start the emulator with my target, without loading any application program?
A: Yes, this mode is interesting if you want to debug your hardware. The following procedure starts the emulator without a program :

  1. Start the Ride7.
  2. Create a new project with 'Project | New' (ex : Debug.prj). Do not insert nodes within the project.
  3. Start the debugging mode with the 'Debug | Start' Debug.aof (Ctrl-d).

In the debugging mode, you will be able to write the assembler mnemonic directly in the Code Window ('View | Code (disassembly)'), and execute the written code with 'Run' and step by step commands. All the peripherals and sfr can be accessed and modified in the monitor mode of the emulator.

Warning!:

  • This mode does not include source debugging and symbol management.
  • The code window is not saved between two debugging sessions.
^PCE FAQs       ^top

Q: Can I emulate a low voltage application with PCE-5130C ?
A: Low voltage applications (3V3 +/- 10%) can be emulated with :

  • RPD-31L : concerns all DIP40 / PLCC44 ROM-less 8051 derivatives.
  • RPD-HK500L and the pod support all the adapters of RPD-HK500, and is especially designed to manage low voltage applications (3V3 +/- 10%).
^PCE FAQs       ^top

Q: Can I emulate the Philips P8XC51RA+/RB+/RC+/RD+ microcontroller including the flash version (P89) with the Raisonance emulator?
A: Yes, you need a PCE-5130C associated with pod RPD-HK500 and adapter ADP-HK501.
In order to replace the emulation MPU on the ADP-HK501's PLCC-44 socket, you need the following reference: PHILIPS P87C51RD+4A for an application frequency from 1 to 12 MHz or
P87C51RD+IA for an application frequency > 12 MHz.

^PCE FAQs       ^top

Q: I have communication errors with PCE-5130C. What can the reasons be?
A: There can be many reasons:

  1. The error message is : "No answer from PCE-5130C" or "The device identifier is invalid or unsupported":
    a) Check the communication port configuration.
    b) Check the serial port : Do you have a conflict with a resident program using this port ?
  2. Other messages during the debugging session.
    a) The PCE-5130C has accidentally been reset (the Run LED is blinking), causing a communication error : please try to terminate it properly ('Debug | Terminate'), or, if necessary, with a Ctrl + Alt + Del.
    b) Some serial ports on computers with "old" serial ports (including a 82C50 instead of a 16C450) do not have hardware with FIFO buffers and can cause communication problems. In such cases, decrease the baud rate.
^PCE FAQs       ^top

Q: What is the maximum frequency accepted by the RPD-HK500 ?
A: The maximum frequency depends on 2 factors :

  1. The RPD-HK500 configuration :
    a) With the Siemens C500 configuration : The maximum frequency is 32 MHz in both ROM-less and embedded ROM mode.
    b) With the Philips configuration : The maximum frequency is 32 MHz in ROM-less and 20 MHz in embedded ROM mode.
    c) With the other configurations : The maximum frequency is 32 MHz (in ROM-less mode exclusively).
    d) With the Dallas mode : The maximum frequency is 25 MHz (in ROM-less mode exclusively).
  2. The emulation MPU maximum frequency :
    a) The RPD-HK500 (and ADP-HK501) is usually supplied with a Siemens SAB-C501-L24M as the emulation MPU. This component has a 24 MHz maximum application frequency. With this MPU, you can work up to 24 MHz, in both ROM-less and embedded ROM mode.
    In order to work at a higher frequency, you must change this MPU for a faster one.
    b) In Philips mode, you are able to emulate your application at 100% of the emulation MPU max. frequency in ROM-less mode and at 75 % of the emulation MPU max. frequency in embedded ROM mode.
^PCE FAQs       ^top

Q: I have the message : "Int. oscillator error : 0.6 MHz". Why does my PCE-5130C emulator not start correctly?
A: If you are using the clock on your target board for the emulator, verify that your microprocessor itself has a suitable clock source (voltage, frequency, and rise/fall-times). You should also verify that the jumper settings on the pod emulator select this as the clock source.
Please also verify your debugging options. This error message can occur if you have not selected the right pod. (See 'Options | Debug | Advanced Options | Pod Selection' under Ride7. Before selecting 'Advanced Options', you must have selected 'Real Machine (Emulator or ROM-Monitor)' under 'Tool' along with 'PCE-5130C' under 'Real Machine'.)

^PCE FAQs       ^top

Q: With the PCE-5130C connected to the target, my application works fine. When I load/burn the code into the microcontroller/EPROM, and I try to run the application without the emulator, it does not work properly.  What can the reasons be?
A: This problem can occur for many reasons :

  1. Is the emulation component an enhanced version of the microcontroller that is installed on your target (eg : 80C32 for a 80C31)?
    The program may access the enhanced resources which are available only when using the emulator. Please check your Compiler and Linker options (The 'RAM size' option of your linker may be the problem. It is found in Ride7 following 'Options | Project | LX51 | Linker' under the title 'Miscellaneous').
  2. Have you completely tested your target?
    Check your hardware and especially the Data/Address buses.
    Change the Code and/or Xdata mapping to have the 'target' attribute, and check your hardware ('View | Data Dump | Xdata Mapping' and 'View | Data Dump | Code Mapping' in the Ride7 menu).
  3. Is the emulator set to the same frequency as your target? Check the clock source. 
^PCE FAQs       ^top

Q: The application works properly with a code EPROM or the 'burned' embedded microcontroller, but not with the emulator.  What can the reason(s) be?
A: This situation can have multiple causes :

  1. Check that you use the emulator in the right performance ranges (max frequency, voltage).
  2. If you have peripherals accessible in the XDATA space, check the XDATA mapping (see the Ride7/debugger reference manual).
  3. Check that you use the emulator at the same frequency as the target. This can have an effect on UART management.
  4. If you have a part of the code on the target that cannot be loaded into the emulation memory of the emulator (ex : boot ROM), change the code mapping attribute of this area into the "Target Visual" attribute.
  5. The emulator generates its own electrical noise which might have an effect on the code execution. It is often "ground" noise, which can be reduced by :
    a) Adding a ground cable between the RPD-HK500 ground and the target ground (OV). Connect or disconnect the ground from your target and observe the effect. If your target has a defective ground or some long bus cables, try increasing the quality of the cables.
    b) At high frequencies, the emulator might not work properly with the target crystal as a clock source. Please use the oscillator on the RPD-HK500 as a clock source (internal on XT1 configuration) whenever possible.
    c) In the ROM-less mode application, you should put a 100 pF ceramic capacitor between the ALE signal of your target and ground to avoid glitches on ALE.
    d) When your application includes some sensitive analog circuits, the PCE-5130C switching power supply can cause abnormal noise that might disturb some applications. In this case, use a linear 5V/3A power supply for the emulator.
^PCE FAQs       ^top

Q: What is the right way to switch the emulator and the target application on and off?
A: When the emulator is connected to a target application, care must be taken to power on and off the system in the right order:

  • To switch the system on : First switch on the emulator, then the target
  • To switch the system off : First switch off the target, then the emulator.

If you do not respect this process, you can damage the target and/or the emulator.

^PCE FAQs       ^top

Q: Why does the instruction MOVX not run properly with the RPD-HK500 probe and the 80C32 microcontroller ?
A: The MOVX instruction makes an access (read or write) in the external RAM, or peripheral within the target, via the external bus P0 (A0-07, D0-D7), P2 (A8-A15), and also P3.6 (/WR) and P3.7 (/RD).

  • Check the general connections of the emulation system : Check the polarity of all subsets (emulator, RPD-HK500, flexible PCB cable, RPD-HK500).
  • Check the connection between ADP-HK501 and the target board. Check all the signals used in a MOVX.
  • Is the target powered ?
  • Is the target voltage compatible with the RPD-HK500 (5V +/- 10%) ?
  • Check the emulation mode, and make sure that you are in ROM-less mode.
  • Check the View|Data Dump[Xdata mapping. For further information on this subject, see the PCE-5130C reference manual. 
^PCE FAQs       ^top

Q: Why does the emulator detect another pod (or MCU) on 'start debug'?
A: The error on pod is detected with the error "message A POD different than specified has been detected!", which occurs on start debug.
The error on MCU is seen after the start debug, opening the View| Debug Report
If the pod is not detected , please check:

  • The general connections of the emulation system : Check the polarity of all subsets (emulator, RPD-HK500, flexible PCB cable, RPD-HK500),
  • The connection between ADP-HK501 and the target board,
  • The pod selection within the PCE-51x0C options.

If the MCU is not detected , please check:

  • If “Siemens C500” is set as microcontroller family, check the MCU selected in the combo box,
  • If “PHILIPS”, “TEMIC”, or “Others” is selected as microcontroller family, no MCU is selected. An automatic detection will be processed and the exact (or nearest MCU) will be detected. The views on corresponding peripherals will be available (the list of the detected MCUs being always evolutive, it will not include the very new MCUs that you should put as an emulation component). 
^PCE FAQs       ^top

Q: Why does the PCE-5130C not work in embedded ROM mode with the RPD-HK500? Why am I not able to use P0 and/or P2 as I/O ports?
A: The reasons why P0/P2 are not able to be I/O can be caused by a number of reasons:

  1. Is the emulation MPU a Philips/Signetics or Siemens MPU?  If not, you cannot emulate this MPU in embedded ROM mode (ROM-less mode only).
  2. If the MPU is correct, please check the RPD-HK500 advanced options. For setting the advanced options, open the menu 'Options | Debug', check 'Real Machine' under 'Tools' and choose 'PCE-5130C' under 'Debug Tool'. Click on 'Advanced Options', choose 'RPD-HK500' under 'POD Selection' and click on 'Config'. Choose according to your MPU 'Siemens C500' or 'Philips' under 'Microcontroller family' and 'Embedded ROM' under 'ROM'.
  3. Before selecting the embedded ROM mode, you have to reset the system (emulator and target). To achieve this switch off first the target, then the emulator; after that, switch on the emulator before the target.
  4. Does the emulation MPU installed on the ADP-HK501 accept the application frequency ? If not, the emulation cannot work properly. For the maximum frequency accepted by RPD-HK500, please consult the FAQ under 'General | 8051 Emulators'.
^PCE FAQs       ^top

Q: The timer 2 of the Siemens C508 does not count correctly.
A: This problem has been encountered with some oscillators. Try a different oscillator.

^PCE FAQs       ^top

Q: Can I emulate Dallas derivatives? What are the restrictions?
A: You can emulate some DALLAS derivatives :

DS80C310 / DS80C320 : With RPD-31F (max freq. 33 MHz) or with RPD-HK500 (max freq. 25 MHz).
DS80C323 : With RPD-31L (max freq. 16 MHz).
DS87C520 : In ROM-less emulation mode with RPD-31F (max freq. 33 MHz) or with RPD-HK500 (max freq. 25 MHz).

DS80C390: can be emulated.

^PCE FAQs       ^top

Q: Am I allowed to exercise software control of the ALE signal on the PCE-5130C?
A: Some derivatives of the 8051 allow to control the ALE signal by software, in order to reduce EMI. A special register turns off the ALE signal.
This action on the ALE signal is inappropriate with the PCE-5130C, because this signal is needed for the emulation.

^PCE FAQs       ^top

Q: Is it possible to measure the duration of an external signal with PCE-5130C/40C?
A: Yes. You must use a wire of one of the probes connected to either PortA or PortB on the PCE5130C/40C, together with the trace.

  1. Connect one of the probes to the signal you want to measure, let's say you use the probe PA.0.
  2. Start the debugger and bring up the trace with the View|Trace|View menu. You will see that PortA appears in the columns in the top pane of the trace window.
  3. Set the trace options: right click in the top pane of the window and choose options.
    In the TRACE tab select Mode=OnChanges and maximum number of records=100.
    In the VIEW tab make sure that "display relative time" is checked.
    In the PORT tab check PA.0: this tells the emulator to record the trace every time there is a change on this signal.
  4. In the main trace window click on PA.0, so that this signal is displayed in the graphical part of the window as well.
  5. Now run your application, stop it (by hand or with a breakpoint) and just go back to the trace window to see the duration of your signal.

Emulation of the ATMEL T89C51RD2 (40 or 44 pins).

^PCE FAQs       ^top

Q: Can I emulate the Atmel T89C51RD2 with PCE-5130C/PCE-5140C and RPD-HK500 ?
A: The answer depends on the application :

  1. If your application uses P0 and P2 as Addresses/ Data bus (ROM-less emulation mode), the answer is YES. You just need to put the Atmel T89C51RD2 to be emulated into the ADP-HKxxx adapter, and select the 'Others' configuration with 'Options | Debug | Advanced Options | Config | Others' in Ride7.
    In 'Advanced Options' select 'Real Machine' and 'PCE-5130C-40C',
    In 'Config' select 'RPD-HK500'.
    The frequency limitation is due to the RPD-HK500 pod: 32 MHz in 12 clock mode, and 16 MHz in 6 clock mode.
  2. If your application uses P0 or P2 as I/O, you can't use the T89C51RD2 as an emulation MPU, but you can use the Philips MPU P89C51RD2, a very similar derivative. In the emulator options, choose Philips emulation mode (select it in the RPD-HK500 options).
    Restrictions : Some differences exist between P89C51RD2 and T89CRD2. If you choose this solution, please make sure not to use (at least during the debugging process) the following features of the ATMEL, that don't exist in the PHILIPS MPU :
    • The 2KB EEPROM (cf EECON, EETIM sfr)
    • The XRAM size selection (cf AUXR sfr)
    • Stretch MOVX control (cf AUXR sfr)
    • X2 mode selected by software

The frequency limitation is due to the RPD-HK500 and the PHILIPS emulation mode : 20 MHz in 12 clock mode, and 12 MHz in 6 clock mode.

^PCE FAQs       ^top

Q: What are the features & limitations with emulation of X2 derivatives with PCE-5130C/5140C and RPD-HK500 ?
A: There are more and more X2 derivatives in the 8051 market.
This technique consists in surpressing the clock pre-scaler within the 8051 core.
The 12 clock per machine initial cycle operation is moving to 6 clock per machine cycle operation, with the X2 mode.

The manufacturers have different ways to implement this feature:

  • Philips (with the 8XC51RX2) has chosen to give the possibility to work at 12 clock or 6 clock, by setting an OTP configuration bit. This bit is programmable with an MPU programmer.
  • Infineon (with the C505x, C515C, etc...) has chosen to fix the mode to 6 clock, in the mask.
    There is no possibility to change for 12 clock mode (8051 initial core).
  • Atmel, (with the 8XC51RX2, 89C51CC01, etc..) has chosen to change the mode (from 12 clock to 6 clock mode, or vice-versa), by software, via the CKCON SFr.

PCE-5130C-5140C configuration :
The emulation options differ with the emulation mode and component family :

  • Philips derivatives in embedded ROM mode : In this mode, the 6 clock (X6), is configured in the RPD-HK500 : Select Philips as microcontroller family, embedded ROM mode, and No Clock prescaler (X6).
  • Philips derivatives in ROM-less mode : In this mode, the 6 clock (X6), is automatically recognised when starting the debugging session : Select Philips as microcontroller family, ROM-less mode.
  • Infineon derivatives : Select the SIEMENS C500 and choose the MPU within the combo box. No other configuration is needed.
  • Atmel derivatives : Select the Temic and ROM-less configurations. When X2 mode is selected in the software, the emulator will synchronise correctly, without loosing any information.

Limitations with PCE-5130C/5140C : Some restrictions exist when using the X2 mode.

    • The maximum emulation frequency will be divided by 2 , compared with the 12 clocks mode.
    • With the PCE-5130C, the time and date within the trace records are divided by 2 (the number of cycles are OK). To correct manually the problem, open the Option|Debug|Advanced Options and change the quartz value to real target frequency.
    • In Philips|Embedded ROM mode, and with "No Pre-scaler" selected, you must configure the clock source into Internal Oscillator on XT1 (see pod configuration). Change eventually the 12 or 16 MHz oscillator for the same frequency as your target board. If you don't find the exact value, you can make yourself an oscillator (see FAQ on the subject).
^PCE FAQs       ^top

Q: Can I easily make my own oscillator, for emulation needs, when the frequency value is not available in the components market ?
A: Why an oscillator is better: The emulator is synchronised with the clock signal which can be (depending on the pod configuration ) :

  • Internal on XT1 : The clock signal is the DIP14 oscillator installed on the pod (typically RPD-HK500).
  • Target crystal : The clock signal is the target crystal (XTAL1, XTAL2).
  • External on XT1 : The clock signal is the target oscillator (XTAL1).

We can easily understand that the target crystal configuration is the worst : The clock signal coming from a crystal has a bad signal/noise ratio. It is disturbed by other target signals, bad grounds, power supplies, etc..
Its only advantage is that the emulation frequency will be the same as target frequency.
When it is possible, and in the following cases, it is much better to use the “Internal on XT1” configuration :

  • When the emulation frequency is higher than 24 MHz
  • When the emulated MPU is a high speed architecture (Dallas core, or X2 core)
  • When the XTAL2 output is not used by another circuit within the target.

It is necessary to use the “Internal on XT1” configuration in the following case :

  • Emulation in Philips | Embedded ROM mode, and “No Prescaler” (X2) selected.
  • With some adapters (ex : ADP-HK508).

How to use the internal oscillator ?
The supplied oscillator is clocked 12 MHz or 16 MHz.
To use the internal oscillator as clock source :
- Configure the pod for “Internal on XT1” (see pod reference manual).
- If necessary, change the oscillator for the same frequency as your target crystal. If you don’t find available the good frequency, you can make your own oscillator (see above).

How to make your own oscillator ?
If  you have a non-standard frequency on your target, you will have to make your own oscillator.
2 examples are given in the “PHILIPS 74HC/HCT4060 14-stage binary counter with oscillator” data sheet (See below figures 10 & 11). For further details, download the complete data sheet :

http://www.philipslogic.com/products/hc/pdf/74hc4060.pdf

 

 ***********************************************************************************

  image 1       image 3

 

 

*********************************************************************************** 

^PCE FAQs       ^top

  

Q: How can I extend the emulation memory of the PCE from 128 Kb (default) to 512 Kb?
A: In its standard configuration, the PCE-5140C emulator is supplied with 128 Kb of code memory. This capacity can be extended to 512 Kb by the user. To extend the addressable space from 128 Kb to 512 Kb, operate as follows:

  1. Power off the emulator.
  2. Remove the CE mark.
  3. Remove the screw.
  4. Remove the bottom part of the plastic box, which includes switcher and BNC, by making it slide.
  5. Remove the 2 SRAM (1Mbit) from the SOJ40 socket.
  6. Insert the 2 SRAM (4 Mbit) into the SOJ40 socket,  respecting pin 1 indicated on serigraphy as "512 BK" (attention : Pin 1 of the socket does not correspond to Pin 1 of the SRAM !!
  7. Assemble the 2 parts of the box together.

No software configuration is necessary.

Note about SRAM for memory extension: The SRAM has the following features :

  • SOJ36
  • 5V power supply
  • Revolutionnary pinout
  • High speed access time (15 nS or less)

Manufacturer reference (examples):

  • SAMSUNG K6R4008C1D-JC12
  • ALLIANCE AS7C4096-15JC
  • CYPRESS CY7C1049B-15VC
    ^PCE FAQs       ^top

Q: Can I emulate a page mode architecture with PCE-5130C-5140C ?
A: In this architecture, external data memory addresses are one byte wide (using P0).
P2 (or a part of) is optionally used as I/O lines, to page the RAM, as shown in the following figure 5 (taken in the PHILIPS Data Handbook IC20) :
Access to the external RAM, uses the movx @ri,A or movx A,@Ri in assembler and pdata qualifier for variables in C language, that affect only P0 , /WR and /RD signals.

Emulation: Page mode architecture emulation is possible only with the Siemens C500 setting of RPD-HK500 options. You must :

  1. Use a Siemens / Infineon as the emulation MCU.
  2. Select  “Embedded ROM” as the ROM configuration.
  3. Select  “only the XDATA (external XDATA)” in Application uses.

Emulation MCU: With an ADP-HK501, choose the INFINEON SAB-C513AO-LN (superset of 80C32/52) or SAB-C501G-LN (discontinued) or SAB-C501G-L24N (discontinued).

^PCE FAQs       ^top

Q: Can I emulate Flash derivatives with PCE-5130C-5140C?
A:
ISP interface
The PCE-5130C-5140C can emulate such derivatives, but the ISP (In system Programming) is not supported. During emulation, all routines using ISP will not work properly.
(The reason is that the application code, at the beginning of a debugging session, is loaded into the emulator memory, and the code is executed from this memory. Even if the Flash MCU is programmed with the application code, no access will be made to the internal code within the Flash memory.)

Embedded ROM emulation
Only Philips derivatives can be emulated properly in embedded ROM mode. That means, that P0 and P2 can be used as I/Os.
Other derivatives (ex: Atmel), can be emulated only in ROM-less mode (P0 and P2 are always bus/ data buses. However, when an Atmel derivative is very similar to a Philips derivative, you will be able to emulate it in both ROM-less and embedded ROM mode, by using the Philips MCU as the emulation component (ex : 89C51RD2)

Putting the Flash derivative as emulation MCU
When you put a Flash derivative (89Cxx) on the emulation MCU socket (ex : ADP-HK501), make sure that this component is not blank. Flash components are supplied in a special mode where, at reset, an internal boot loader is accessed (typically located at 0xFC00 of the code space). This mode allows programming the Flash memory with the ISP but is not compatible with emulation process, that needs to boot at the address 0x0000. Programming the MCU (any program will be convenient), makes the MCU start code access at 0x0000.

^PCE FAQs       ^top

Q: How can I connect my Raisonance emulator to a PC with no serial port (or with serial port problems)?
A: A USB to Serial converter exists that can be successfully used to connect the emulator to the PC.
This is of course useful for the smaller PCs without any serial port, but it can also be used for PCs whose serial port does not work well with Ride7 (the latest Dells have some sort of polling on the serial port that interferes with Ride7).
USB to serial adapters usually come with a driver that creates a virtual COM port (usually COM3 or COM4) that can be selected in Ride7. The reference "USB to Serial Adapter cable ref : DA 70119" from Assmann has been tested and is guaranteed to work.

^PCE FAQs       ^top