This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Bizzar problem

Hello all,
I have a bizarre problem that I hope someone will be kind to help me.
I'm working with compiler ver7.02b, RTX51-full, and T89C51RD2.
One of the variables (X) placed in xdata (address 0x19CC) is initialized to 3. For some bizarre reason when program is running this value is changed to zero. There isn't any place in my code where I set this variable to zero, because it's illegal in my case (acceptable values can be from 3 to 255).
The compiler's optimization level is set to zero.
I'm using Ceibo's emulator DS-51, but he doesn't support software breakpoints with write specific data to specific address location (I wanted to stop execution when zero is written to this specific address location).
Does someone have any idea how to proceed?

Thanks in advanced,
Ruven

Parents Reply Children
  • My code does not have reentrant functions.
    I only change the memory space definitions in the STARTUP.A51 file to:

    IDATALEN	EQU	100H	;
    XDATASTART	EQU	0H	;
    XDATALEN	EQU	10000H	;
    PDATASTART	EQU	0H	;
    PDATALEN	EQU	80H	;
    
    P.S.
    This variable is placed in XDATA. When I place it in DATA, it's OK, but due to lack of memory space I can't use the DATA space (only XDATA).

    R.H

  • One of the variables (X)
    what is the secret?
    char, int, or whatever ?
    banked or not ?
    accessed in an interrupt or not ?
    what about a code snippet ?

    Erik

  • First of all, for some reason I don't receive an email notification when someone posts to this thread (I checked the notification box and my email address is correct). So every couple of hour I check this discussion list.
    Second, sorry for not giving enough details. The variable is a member of a struct where the struct variable is a global one. I declare and use it as follow:

    CH_PARAM xdata stCHprm;
    void func()
    {
      stCHprm.msgFltr = 3;
    }
    
    .
    I can't post all code where I use this variable because it's in some functions/tasks. I know (also checked) that only one task/function is accessing this variable in any given moment.
    banked or not? I don't use banking.
    access in an interrupt or not? Not.

    For the Keil's build-in simulator, I can't use it because I use LCD and I have an lcd_rd function that waits until LCD is free. The simulator can't access/operate the LCD. But this is another story…

    I hope all these will drop some light on the solution.
    Thanks,
    Ruven

  • "For the Keil's build-in simulator, I can't use it because I use LCD"

    Someone has posted an LCD simultation here for use wit uVision - try a 'Search'

    "The simulator can't access/operate the LCD."

    Nothing unusual there - you will either have to use the simulator's facilities (debug and/or signal functions) to provide the necessary stimulus, or write a simulation "stub", or do it manually with the help of breakpoints.
    All standard techniques for simulation.

  • Hi Andy,
    I know that if I will write something about the built-in simulator the answers/help will be focus on that subject.
    As I wrote before, I have the Ceibo's emulator and also with him or without him I can't determine the cause of this bizarre problem.
    I made an experiment to set the variable in specific XDATA address location by using _at_ word. Now it seams to be OK.
    My added question is what is the reason for what happened?
    Why the program (maybe the operating system) sets a value in a global variable where no one asks him to do so?

    Thanks,
    Ruven

  • If moving the variable to another address changes the behaviour, this points at a buffer overrun or other wild pointer as the most probable reason. I.e. a bug somewhere in your code happens to construct a pointer to the address this variable is normally located, and overwrites it. Move it away, and that same bug will hit unused memory, or some other variable that now lives there.

    I strongly doubt there's any reasonable way you'll manage to track down this one without data write access breakpoints. About the only alternative would be to comment out larger and larger pieces of your program until the bug vanishes, then reactive parts of what you removed until it reappears. Repeat until you home in on some piece of it that misbehaves, and find the bug by just looking at the code in question (or posting it here...).