Keil Logo

MON51: STRANGE BEHAVIOR OF PROGRAM CODE


Information in this article applies to:

  • C51 Version 6
  • C51 Version 7

QUESTION

I have created a simple program that works fine when run without the monitor. However, when I use MON51 to single-step through the program, data in code space gets corrupted. My program is written for the Cypress EZ-USB. For debugging, I have enabled Stop Program Execution with Serial Interrupt under Options for Target - Debug - Keil Monitor-51 Driver Settings.

unsigned char code password[PASSWORD_LEN+1] = "12345678";
unsigned char TestBuf[PASSWORD_LEN];

unsigned char *pRead, *pWrite;

 pRead = password;
 pWrite = TestBuf;
 for (i=0; i<PASSWORD_LEN; i++)
   *pWrite++ = *pRead++;

In the above program, the linker reports that the password variable is located at C:0036H.

When I start debugging with MON51, I can view the Memory window and see that C:0x36-C:0x3D actually contains the values 0x31-0x38 (which is the correct value for the ASCII characters 1-8).

But when I execute the for loop, I find that the contents of password is changed to 0x31, 0x32, 0x33, 0x34, 0x35, 0x02, 0xEA, 0xB1.

The program seems to work fine without the monitor. Do I have a configuration problem somewhere?

ANSWER

It appears you are using the second on-chip UART for debugging with MON51. This UART uses the interrupt vector at address 0x003B-0x003D. This is right in the middle of your password string. When you start the Monitor, it overwrites the interrupt vector location for the UART. And, that's where the 0x02, 0xEA, 0xB1 bytes come from (they are an LJMP instruction).

To avoid this problem, your application must reserve (and not use) the memory location of the interrupt vector.

When debugging with the classic 8051 UART, insert the following line in one of your source files:

char code reserve [3] _at_ 0x23; /* for Monitor-51 serial interrupt */

For the second UART of the Cypress device, enter:

char code reserve [3] _at_ 0x3B; /* for Monitor-51 serial interrupt */

MORE INFORMATION

SEE ALSO

Last Reviewed: Wednesday, August 3, 2005


Did this article provide the answer you needed?
 
Yes
No
Not Sure
 
  Arm logo
Important information

This site uses cookies to store information on your computer. By continuing to use our site, you consent to our cookies.

Change Settings

Privacy Policy Update

Arm’s Privacy Policy has been updated. By continuing to use our site, you consent to Arm’s Privacy Policy. Please review our Privacy Policy to learn more about our collection, use and transfers
of your data.