EmbeddedRelated.com
Forums
The 2024 Embedded Online Conference

Keil compiler or FX2 ?

Started by Thomas Hoppe May 7, 2004
Hi !

I have some mysterious problems with cypress fx2. Sometimes if I make small
changes in our firmware things go wrong (mostly the enumeration process
failes). After adding some stupid line of code (BYTE xdata dummy[] =
"dummy";) it works as expected !
I don't know what's responsible for this problem. Compiler ? Linker ? FX2 ?
Perhaps anybody has some experience with this kind of problems.
My predecessor had the same problems and they occur on different hardware
using the fx2. Thats why I think is not related to a wrong code line or
defect hardware.

Many thanks,
Thomas Hoppe


Thomas Hoppe <black.hobbit@gmx.de> wrote:

> I have some mysterious problems with cypress fx2. Sometimes if I > make small changes in our firmware things go wrong (mostly the > enumeration process failes). After adding some stupid line of code > (BYTE xdata dummy[] = "dummy";) it works as expected !
That sure feels like a bug in your software. That line, e.g., introduces a new variable in xdata, which will move a good fraction of your entire xdata to new positions. The kind of bug that is affected by this is writing through a garbage pointer. Moving things around means you change what gets hit by that bomb. -- Hans-Bernhard Broeker (broeker@physik.rwth-aachen.de) Even if all the snow were burnt, ashes would remain.
"Thomas Hoppe" <black.hobbit@gmx.de> wrote in
news:c7fgfi$hdo$1@news.f.de.plusline.net: 

> I have some mysterious problems with cypress fx2. Sometimes if I make > small changes in our firmware things go wrong (mostly the enumeration > process failes). After adding some stupid line of code (BYTE xdata > dummy[] = "dummy";) it works as expected ! > I don't know what's responsible for this problem. Compiler ? Linker ? > FX2 ?
Neither. The C run-time is responisble for copying the DATA section constants, like "dummy", to their final run-time locations (e.g. FLASH to XDATA) and zeroing BSS variables (those without an initial value). To see why adding the BYTE xdata dummy[] = "dummy"; line affects, switch to assy. mode in the debugger and watch the CSTARTUP.ASM code execute. My guess is that you have some variable that is not properly initialized but in certain cases happens to be the correct value. Adding a dummy[] causes something other than what you want to be placed in this as-yet-to-be-found variable and things go wrong. Rule 1: reduce your dependence on the C run-time. Don't use global or file scoped variable when not absolutely required. Rule 2: Don't assign values to global or static variables because it increases your image size. Rule 3: If you can initialize variables at run-time, do so e.g. strcpy(dummy, "dummy"). -- - Mark -> --
based on what you are just saying, (and only on what you are saying), you
got a compiler bug buddy........  Ive chased them around for years........
if you can add a "do nothing" line of code, and it fixes your problem, then
you can almost bet your ass on it............   actually, i would think a
linker bug, more than the compiler itself......

"Thomas Hoppe" <black.hobbit@gmx.de> wrote in message
news:c7fgfi$hdo$1@news.f.de.plusline.net...
> Hi ! > > I have some mysterious problems with cypress fx2. Sometimes if I make
small
> changes in our firmware things go wrong (mostly the enumeration process > failes). After adding some stupid line of code (BYTE xdata dummy[] = > "dummy";) it works as expected ! > I don't know what's responsible for this problem. Compiler ? Linker ? FX2
?
> Perhaps anybody has some experience with this kind of problems. > My predecessor had the same problems and they occur on different hardware > using the fx2. Thats why I think is not related to a wrong code line or > defect hardware. > > Many thanks, > Thomas Hoppe > >
Clark G. Smith <clarkgsmith@comcast.net> wrote:
> "Thomas Hoppe" <black.hobbit@gmx.de> wrote in message > news:c7fgfi$hdo$1@news.f.de.plusline.net...
> > I have some mysterious problems with cypress fx2. Sometimes if I > > make small changes in our firmware things go wrong (mostly the > > enumeration process failes). After adding some stupid line of code > > (BYTE xdata dummy[] = "dummy";) it works as expected !
> > I don't know what's responsible for this problem. Compiler ? > > Linker ? FX2 ? Perhaps anybody has some experience with this kind > > of problems. My predecessor had the same problems and they occur > > on different hardware using the fx2. Thats why I think is not > > related to a wrong code line or defect hardware.
> based on what you are just saying, (and only on what you are saying), you > got a compiler bug buddy........
You're jumping to conclusions way prematurely. At the level of details shown by the OP, there are quite a lot of possible reasons left that could be at the bottom of this. A bug in the toolchain, while never quite impossible, is by no means the most likely of them, and certainly not the only possible one. Bugs in the OP's own code are quite a bit more likely. -- Hans-Bernhard Broeker (broeker@physik.rwth-aachen.de) Even if all the snow were burnt, ashes would remain.

The 2024 Embedded Online Conference