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

C51 v7.20 WinXP Exception

We have a new machine running a new version of the compiler that's having a problem. It's Cx51 v7.20, run from uVision, on top of WinXp Media Center Edition (hey, it was there), plus Cygwin.

When the compiler runs, a couple of "send problem report to Microsoft" exception dialogs pop up when compilation reaches a particular couple of files. It's always the same two files, which may be just a matter of when they're reached in the compilation process, or perhaps something about the files themselves.

There's nothing wrong with the project or these particular files. We have two other machines (running XP Pro pre- and post-SP2 and C51 v7.05 / v7.09) that work fine on exactly the same input (project files and source).

Sound familiar to anyone? Any suggestions on what might be going wrong?

  • "Cx51 v7.20, run from uVision, on top of WinXp Media Center Edition"

    Well, that's not exactly what a "Media Centre" is for, is it...? ;-)

    Do these compilations crash if you just translate them individually, rather than as part of a Project (re-)build?

    "There's nothing wrong with the project or these particular files. We have two other machines (running XP Pro pre- and post-SP2 and C51 v7.05 / v7.09) that work fine on exactly the same input (project files and source)."

    Do these machines have exactly the same pathnames as the "Media Centre" machine for everything?
    It was a few versions back, but we did see some bizarre effects where different paths could cause the build to crash or not!
    I seemed to be something to do with the QVCS keyword expansions...

  • that's not exactly what a "Media Centre" is for, is it

    But I want to use the universal remote control to start the compilation and synchronize the code generation to background music from the CD!

    Good suggestions, but they don't seem to be the case.

    Further investigation reveals:
    If I copy the 7.05 c51.exe and cx51.exe onto the troubled machine, it works fine.

    Contrariwise, if I put the 7.20 executables into the C:\keil\c51\bin directory of a working sytem, I get the same compiler crash on the same two source files.

    Looks like a bug in the 7.20 compiler. Perhaps I can isolate the bad sources enough to be useful to tech support.

    Incidentally, I misreported the compiler we're using. It's C51, not CX51.

  • Bug report is in to tech support. Here's an example that triggers the bug. (I don't know if project settings are important.)


    #include <stdlib.h>
    #include <stdio.h>
    
    #define	MY_BASE				0xbeeefL
    #define MyAddress(offset)	(MY_BASE + (offset << 3))
    #define PortTable(offset)	((volatile unsigned int *) MyAddress(offset))
    #define PortVal				PortTable(0xbcd)
    
    void main (int argc, const char * const argv[])
    {
    	unsigned int ui;
    
    	if (argc > 3)
    	{
    		ui = strtoul (argv[3], NULL, 0);
    
    		PortVal + 1;
    	}
    }
    
    
    

  • Drew:

    There are several things wrong with your code.

    First, this apperas to be the source to a DOS program, not an embedded program. There is no idle loop. Embedded programs don't take arguements. The main must be defined as void main(void).

    Second, PortVal + 1; is not a valid line of C code. You need to say either PortVal += 1; or x = PortVal + 1;

    Third, the value of MY_BASE is outside the 8051's address range. This project is set up as a Small Memory Model, so the default memory space is DATA, which only has an eight bit address bus. There is no way you can use a 32bit value to address your table.


    Best Regards,
    Brian Clough
    Technical Support Analyst
    Keil Software, Inc.

  • "Second, PortVal + 1; is not a valid line of C code."

    Surely it is valid - but pointless!?

    "Brian Clough
    Technical Support Analyst
    Keil Software, Inc."


    So rumours of your death have been greatly exaggerated:
    http://news.bbc.co.uk/sport1/hi/football/1576977.stm
    http://football.guardian.co.uk/print/0%2C3858%2C5020609-103%2C00.html
    http://news.independent.co.uk/low_res/story.jsp?story=563960&host=3&dir=271

  • So rumours of your death have been greatly exaggerated:


    It's Strange how rumors about ones death get started.

    Elvis Presley
    Elvis.Presley@graceland.net

  • I emailed Brian a new file earlier today. So, for those of you that like to play along at home:

    #include <stdlib.h>
    #include <stdio.h>
    
    #define	MY_BASE				0xf000
    #define MyAddress(offset)	(MY_BASE + (offset << 3))
    #define PortTable(offset)	((volatile unsigned int *) MyAddress(offset))
    #define PortVal				PortTable(0xbcd)
    
    void cmd (int argc, const char * const argv[])
    {
    	unsigned int ui;
    
    	if (argc > 3)
    	{
    		ui = strtoul (argv[3], NULL, 0);
    
    		ui = PortVal + 1;
    //		ui = ((volatile unsigned int *) (0xf000 + (0xbcd << 3)));
    	}
    }
    
    void main (void)
    	{
    	cmd (2, NULL);
    	for (;;);
    	}
    
    

    There. More like a real program now, though of course still pointless.

    The point, of course, is to have a minimalist example that produces the problem (whether it does anything useful or not). This code is a stripped and santized version of the real thing, a eidolon of its original form devoid of real meaning and purpose in life.

    The "PortVal + 1" line causes the 7.20 compiler to access memory out of bounds (Windows exception 0xc0000005). The commented line, where the macros have been expanded by hand, does not cause a crash. This makes me suspect the preprocessor. 7.05 will compile either version.

    I didn't try to get the example to link. Among other things, it's missing an L51_BANK and bank switching is enabled in the project file.

    My coworker (who actually is the one experiencing the problem) mentioned that removing the #include's will cause the compiler to successfully complete, but I haven't tried that myself.

  • I emailed Brian a new file earlier today. So, for those of you that like to play along at home:

    #include <stdlib.h>
    #include <stdio.h>
    
    #define	MY_BASE				0xf000
    #define MyAddress(offset)	(MY_BASE + (offset << 3))
    #define PortTable(offset)	((volatile unsigned int *) MyAddress(offset))
    #define PortVal				PortTable(0xbcd)
    
    void cmd (int argc, const char * const argv[])
    {
    	unsigned int ui;
    
    	if (argc > 3)
    	{
    		ui = strtoul (argv[3], NULL, 0);
    
    		ui = PortVal + 1;
    //		ui = ((volatile unsigned int *) (0xf000 + (0xbcd << 3)));
    	}
    }
    
    void main (void)
    	{
    	cmd (2, NULL);
    	for (;;);
    	}
    
    

    There. More like a real program now, though of course still pointless.

    The point, of course, is to have a minimalist example that produces the problem (whether it does anything useful or not). This code is a stripped and santized version of the real thing, a eidolon of its original form devoid of real meaning and purpose in life.

    The "PortVal + 1" line causes the 7.20 compiler to access memory out of bounds (Windows exception 0xc0000005). The commented line, where the macros have been expanded by hand, does not cause a crash. This makes me suspect the preprocessor. 7.05 will compile either version.

    I didn't try to get the example to link. Among other things, it's missing an L51_BANK and bank switching is enabled in the project file.

    My coworker (who actually is the one experiencing the problem) mentioned that removing the #include's will cause the compiler to successfully complete, but I haven't tried that myself.

  • It fails on my system here as well. I forwarded your example to engineering.

    Jon

  • "This makes me suspect the preprocessor"

    Do you mean you suspect that the preprocessor is crashing, or you suspect that the preprocessor is generating something that makes the compiler crash?

    If the latter, have you tried looking at the preprocessor listing?

  • Checking the preprocessor listing box gave me some odd results. The first time I tried it, the compiler ran successfully. Turn the .i off, crash. On, runs. Off, crash.

    I played with that briefly, restarted uVision, and now the compiler crashes either way.

    But to answer the question, the behavior made me suspicious of the processor itself, perhaps some sort of buffer overflow while recursively expanding those four #define's.