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?
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 (;;); }
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.