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

Compiler problem while adding global variables

Hi everybody,

i have detected some absurd behavior in my project.
In not determinated intervalls i have a repeating problem with my At89c51Re2 software.

Now i reduced the Problem to a minimum.

Anywhere in my code i add a simple global variable (like static UINT32 g_ParameterChecksum = 0;) and the following code triggered the impossible error.

static UINT8 g_DigitalByteValue = 0;

...

        g_DigitalByteValue = 0;
        if (g_DigitalByteValue != 0)
        {
                Debug_ErrorOutput("Compiler Error? @digout");
                Error_FatalError(ERROR_UNKOWN);
        }
...

when i removed the new variable it works well.

I am use code banking,funtion pointers, interupts and Uv3 (from command line).
Program Size: data=233.1 xdata=8183 const=112 code=91375
Maximum block depth: 8

i suggest that some addresses pointers are mixed up, but i does not know why.

Has somebody a hint or solution for this problem?

Thanks a lot,
David

Parents
  • Do you run out of RAM (etc)

    That (in itself) shouldn't be the problem here. The disassembly shows a clear of ACC, write to memory and then a test of ACC. That is, it does not read back the contents of the memory. So even if it was writing to nowhere (or somewhere wrong), it should not affect the test.

    0002 E4                CLR     A
    0003 900000      R     MOV     DPTR,#g_DigitalByteValue
    0006 F0                MOVX    @DPTR,A
                                               ; SOURCE LINE # 61
    0007 600B              JZ      ?C0002
                                               ; SOURCE LINE # 62
    

Reply
  • Do you run out of RAM (etc)

    That (in itself) shouldn't be the problem here. The disassembly shows a clear of ACC, write to memory and then a test of ACC. That is, it does not read back the contents of the memory. So even if it was writing to nowhere (or somewhere wrong), it should not affect the test.

    0002 E4                CLR     A
    0003 900000      R     MOV     DPTR,#g_DigitalByteValue
    0006 F0                MOVX    @DPTR,A
                                               ; SOURCE LINE # 61
    0007 600B              JZ      ?C0002
                                               ; SOURCE LINE # 62
    

Children